Noel J. Bergman wrote:
For example, by the time we're
done, I expect that configure() will be replaced by init(), and we'll have
eliminated the Avalon API from polluting the code.
I don't think that eliminating Avalon API from the code will be so easy.
We have the same problems that we have in Mailets: if you need a service
you have to be Serviceable or to lookup the ServiceManager from the Context.
Imho moving to init is probably a bad move: I prefer to have a clear
dependency on Avalon instead of having an hidden/subtle dependency on
Avalon.
Btw I don't have time for religious container wars ;-) .. I prefer to
keep it to work on my handlerapi proposal and maybe you will like the
"plugin mechanism" I have in mind and maybe we can use it something
similar for Mailets.
As an hint my proposal will include a generic "extension point
mechanism" using an extension manager and "enabling interfaces" for the
dependency injection.
Btw maybe I will not find the time to work on it, and there won't be any
need to discuss about my proposal at all ;-)
Furthermore, generically speaking, I love modularity but I think that
modularity is a weapong to be used with much wisdom. We should never
introduce a modularity that is not needed in the real life because we
probably only add ways to break the system and nothing more.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
