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.
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.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
