james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.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 08:45:25 GMT
Am Mittwoch, den 12.07.2006, 09:45 +0200 schrieb Bernd Fondermann:
> 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 
> about:
> 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.

I like the setter stuff you put in there. With setters its also more
easy to write junit tests. I allready use them for example in
DNSRBLHandlerTest..I don't see any "real" problem with the setter

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

I don't think the revert is a good thing .. See what i wrote above. I
whould be +1 to have it in the code...


View raw message