RE: [picocontainer-dev] Preferring Parameter names.....

Konstantin Priblouda wrote on Friday, September 28, 2007 9:21 AM:

> --- Jörg Schaible <[email protected]>
> wrote:
> 
>>>> An alternative using Parameter objects
>>>> 
>>>>      pico.addComponent(JDBCService.class);
>>>> 
>>>> or ..
>>>> 
>>>>      pico.with(new
>> NamedParameter("jdbc_username"), new
>>>> NamedParameter
>> ("jdbc_password")).addComponent(JDBCService.class);
> 
>>> 
>>> Somehow I prefer this syntax, as it promisses simplier
>>> parameter API
>> 
>> What I don't understand: With that call we have
>> exaclty the scope we need!
>> 
>> pico.with(new NamedParameter("username", "paul :)"),
>> new NamedParameter ("password",
>> "p1")).addComponent(JDBCService.class);
>> pico.with(new NamedParameter("username", "dick"),
>> new NamedParameter ("password",
>> "p2")).addComponent("Foo", SOAPService.class);
>> pico.with(new NamedParameter("username", "harry"),
>> new NamedParameter ("password",
>> "p3")).addComponent("Bar", SOAPService.class);
> 
> I think referring to formal parameter name is not for
> pico proper, as it does not conform to pure vanilla
> java and requires additional  (and not obvious)
> processing of target classes or compiling them with
> debug info (may be unavailable)

Well, the standard paranamer functionality simply looks-up the parameter names from entries in the META-INF. But you have your point, unless this is part of the JDK it does not really help in the current situation and it simply shifts the declaration to a different place.

However, a current component registering like

pico.with(new NamedParameter("username", "paul :)"), new NamedParameter ("password", "p1")).addComponent(JDBCService.class);

simply means, that the CDI algorithm will use the parameters in the sequence they have been delcared and simply ignore the names at all (at least this was Pico 1.x functionality). The introduction of the names was intended for a combined SDI/CDI approach.

>> Weird thought: What if we drop the Parameter
>> altogether? In the end it acts like an intelligent
>> map ... why not use a simple Pico instead? If each
>> component has its own private Pico that has the main
>> container as parent, the lookup is transparent and
>> you can add parameters as instances without the
>> problem that they interfere with parameters of the
>> others? The DPC might be too heavy weight, but if we
>> provide a SimplePC ... ?
> 
> I like current work distribution - container is
> storage, provides lifecycle and hierarchy, component
> adapters provide configuration and instantiation
> behaviour and rely on parameters to obtain
> dependencies.
> 
> We already have:
>  - by key parameters
>  - by type
>  - config ( by key / convert type )
>  - jndi ( get from )
>  - jmx ( get from )

Don't mix this up, these are completely different levels:
1/ by key parameters ==> direct assignment
2/ by type ==> dependency injection
3/ config ==> name injection (?)
4/ jndi (should be merged with JMX anyway) ==> component lookup

> Put everything in pico? 

Didn't say that.

> Too heavy. I think we are
> better off with  aggregation, as it provides simple
> components.

The "simple pico" is more or less a priorized map that tries to solve 1/ and 3/.

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email