james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
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:45:48 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.

JAMES-494 is not about going to extremes. It is focused to having 
setters for all the looked up objects _only_.

This is exactly what the word "inversion of control" is essentially all 
Not the object does look up it's dependency, which currently means
a. the object must know where its dependency is coming from
b. it's lookup name/key
b. object itself becomes dependend on the lookup mechanism (Avalon, 
JNDI, JMock, JamesHomeBrewnRegistry)

Instead, a managing instance (which is there anyway) provides/injects 
the dependencies right away.
So it's about actually reducing dependency on the surrounding framework.

> For the DNS server, I'm thinking that we might want to look at switching to
> JNDI if we can ensure that we'll bypass Java's idiotic handling and go
> straight to dnsjava.

Maybe, but how is that related to the changes I am currently making?

I think converting to an all-JNDI service repository becomes _much_ more 
easy when we have only dumb setter around and container managed injection.

>>Should I revert all of it or only some parts?
> You need not revert anything.  A veto does not mean revert.  It means that
> until the veto is lifted, the code cannot be released.  I am sure that we
> will come to a place that satisfies both of us before we need to worry about
> a release.

Well, I reverted it already. As you will see, the changes I made were 
trivial anyway.
And I still don't get what you are proposing us to do.


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

View raw message