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