On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > I am not sure what you mean by "transparently swap". IoC requires > fairly extensive configuration for this "transparency". I don't see > what is transparent about the IoC setting of an implementation at all. > Am I missing something?
If I use "create at startup", I'm going to get my instance of a service class configured with its own dependencies. For example, if I'm using constructor injection: public class Foo { public Foo(Bar bar) { this.bar = bar; } ... code that uses "bar" ... } Now, in your scheme you upgrade the Bar class (of course, setting up a new class loader to contain it). But what you haven't done is notified my Foo instance that you should somehow update the private "bar" variable to point at a new instance based on the new class (possibly having to do some sort of state transfer as well) ... it continues to use the old one -- with the side effect that the old one will not get garbage collected either. You can tell me to use "create on demand" instead, but then I don't need anything fancier than an IoC framework that lets me reconfigure on the fly. And, current IoC approaches provide me other important benefits: * Multiple implementations can be used without the user having to know the implementation class name. * Don't need the artificial confusion of multiple instances of the same class name. For those reasons alone, I'm satisfied sticking with current IoC approaches, and have sort of lost interest in pursuing this any further. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]