james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Date Wed, 12 Jul 2006 22:58:45 GMT
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

> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message