This does look about as anti-IoC as it gets
Why? Not that IoC is the be-all and end-all of component design.
Nor do I fully understand and preach design patterns. To me IoC is about not having code know what is using it or how it got instantiated or configured. It knows it depends on object/class X, Y, and Z, and something else handled the setting/injecting.
Conversely I would use commons configuration to say, "here mr. object is your configuration" and the object would say, "thank you, I will ask this configuration object for everything I need to initialize myself."
now that I have seen a simple IoC framework in practice, I don't like JNDI and also appreciate what Avalon was trying to do.
Why? IoC requires decorators for each thing being pushed, or pushes an object providing pull access to the things you want. Both of those are present in Avalon.
I wrote this huge response, then deleted it. Here's a better way to say what I mean:
http://docs.codehaus.org/display/PICO/Inversion+of+Control?decorator=printable
I prefer CDI or Setter injection (Spring does these two), while Avalon is Contextualized Lookup.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
