A slightly different approach... As HiveMind is agnostic about the type of dependency injection used it would make sense to colocate the code dealing with both constructor based and setter based dependency injection. Thus, if this were a service, it should really be an implementation factory service. I'll refer to it as the "ServiceFactory".
This would be the core implementation factory service with support for dependency injection. Think of it as a stripped down BuilderFactory. Maybe we could have the <create-instance> element represent this service (as a shorthand) in the module descriptors. This would of course imply that <create-instance> would now also have support for autowiring. The beauty of this would be that every service implementation would be constructed by an implementation factory. What about the ServiceFactory itself then? That would be left as a detail of the registry bootstrap. Which ClassLoader object in a JVM loaded the bootstrap classloader class? I think it's left up as a detail of the JVM implementation. Further the ServiceFactory could be configurable or maybe even be replaced by the user. The BuilderFactory and BeanFactory could delegate part of their job to the ServiceFactory. The reference to it could be injected, but I think it would be cleaner to obtain it by querying the Module object. --knut On Wed, 27 Oct 2004 17:45:03 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote: > So there is a catch (22). Didn't think about that! And it's a very > good reason not to provide a ServiceInjector service. The logic could > still be encapsulated in a class and be reused as such. Even as a > convenience method as Marcus suggests. > > > > --knut > > On Wed, 27 Oct 2004 11:14:44 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> > wrote: > > Don't forget the bootstrap issues; the BuilderFactory can't construct > > itself! So it may have a captive instance of ServiceInjectorImpl that > > would be different from the one accessed (via the normal paths) by > > other services. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
