I think we could have a service and configuration. The configuration contributions look much like the <construct> parameter to BuilderFactory. The service simply allows access to beans specified inside.
Because there aren't proxies for beans, we'll have to be extra careful to detect dependency cycles between beans. In addition, we could define a ObjectProvider for prefix bean: (perhaps that will be the only way to access such beans?) On Tue, 26 Oct 2004 18:11:54 +0200, Knut Wannheden <[EMAIL PROTECTED]> wrote: > On Tue, 26 Oct 2004 11:53:50 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> > wrote: > > I was actually thiking about re-using the BuilderFactory's > > BuilderFactoryLogic and generalzing it a bit so that it can handle > > non-services. In this scenario, BuilderFactory would be the > > specialized case, and POJOBuilder would be the more general case. > > > > I think I see what you mean. Would this POJOBuilder be a service? > And what objects would it be able to wire up a POJO against? Just > loaded HiveMind services or objects from any given set? > > I think a service which can be used to programatically wire up a POJO > (against HiveMind services) would be quite useful. > > I see this being useful in factory services (not "service factory > services" implementing ServiceImplementationFactory, but rather more > general POJO factories). The factory service could then wire up the > POJOs it creates with services loaded in the HiveMind registry. E.g. > > _pojoBuilder.injectServices(createdPojo); > > > Might also be a good chance to revist how we do constructor injection, > > since the current implementation is a bit stupid and weak. > > > > +1 > > --knut > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
