On Wed, Oct 22, 2008 at 6:44 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 22, 2008, at 3:29 AM, Markus Wiederkehr wrote: > >> I also think that Mime4j should not inflict a certain IOC container on >> the user. I want to decide what IOC container to use in my >> application, if any. > > I don't pretend to understand any details of what you are proposing but IMO > it is not too hard to write container-agnostic IOC components (at least for > non-intrusive containers). Then you can write a little bit of code to wire > stuff together when running outside an IOC container, and, if necessary, > adapters for use in intrusive IOC containers.
Sure, for setter base injection all you need is a setter, after all. In our example this would mean that MessageBuilder would not ask for a TempStorageProvider by calling some static getInstance method but would instead provide a setter where such a provider has to be injected. On the other hand MessageBuilder maintains a state (a stack for building the message). So it cannot be easily used as a "service" (or "bean" depending on your IOC container) for building message instances, or am I wrong? Also the API would be a bit clumsy if you decide not to use dependency injection at all. So all in all I'm not sure if it would be worth it. After all all we need is one strategy that is exchangeable on an application level. Markus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
