Stefano Bagnara wrote:
> init(Config) where Config contains a Context that in turn contains a
> mean to retrieve services is just an obfuscated way to use the Avalon
> serviceLocator pattern (service(ServiceManager s)).
Well, you can say obfuscated and I can say that it is the commmon mechanism
used throughout the J2EE specifications for configuring container managed
components. Passing a configuration object from which one can get to a
context object is a common pattern, along with JNDI. But we can agree that
we can have one init() instead of N setter methods, where N is unbounded.
> Imho dependencies have to be shown in the clearest of the ways.
Clear, yes. But everytime you add a new dependency you have to change the
API.
> JNDI is another service locator, but less powerful than ServiceManager.
JNDI is more powerful than the Avalon Service Manager, if one really
understands it.
> In fact with Avalon Serviceable it is easy to have 2 instances of the
> same component configured in totally different ways because they receive
> a different ServiceManager. To do that with JNDI you add one level of
> complexity.
The container is responsible for providing the appropriate InitialContext to
the contained component. No extra levels of anything.
> It would be much better to introduce our own "serviceable" interface
> and if you like JNDI use JNDI inside the ServiceManager you pass
> to the object. This way the plain objects does not depends on JNDI
> but only on the serviceable interface.
Servicable is just a means of providing the lookup service (Service
Manager). If we really want to drink the DI koolaid, we should add a setter
for every service. Then the container can inspect everyone to see what
service(s) they need.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
