james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Date Wed, 12 Jul 2006 07:16:49 GMT
Noel J. Bergman wrote:
> Bernd Fondermann wrote:
>> Well, the intention of this whole thing is to actually _lower_ Avalon
>> dependency. That's not always easy. ;-)
> :-)
>> Currently, I'm simply working on providing means (setters) for Beans to
>> get stuff injected they need and eventually get rid of service(),
>> initialize() + configure() hell altogether.
> I'm not a particularly big fan of DI in the extremes that some take it.
> Adding N setters to M objects and the support code for inspecting who
> implements which DI methods in order to subscribe to those values, compared
> to a single injection as init(Config) doesn't make sense in most cases.

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)).

Imho dependencies have to be shown in the clearest of the ways.

JNDI is another service locator, but less powerful than ServiceManager. 
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. 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. Otherwise, using setters and 
configuration or autowiring by reflection you can also remove the 
interface. I think that interfaces are good and should be kept.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message