I believe I forgot to account for the "scoping" of the autowiring. Somehow we need to be able to tell the injector that we only want it to autowire services from within a specific module. I believe that's how the default autowiring works now. Is this to avoid the situation where another module declares the same service interface as a different service point, thereby breaking your module's autowiring?
-----Original Message----- From: Marcus Brito [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 11:12 AM To: [email protected]; Howard Lewis Ship Subject: Re: Simple Bean injection The scenario here are legacy "services": suppose that for some unfathomable reason you can't build/expose a service in the hivemind registry, but you'd love to satisfy this service's dependencies from a hivemind registry. So, we need something like this: CrapService myCrap = new CrapService(); Registry registry = <... get the registry from some context, attribute, etc> registry.injectDependencies(myCrap); This would try to "autowire" the myCrap object with services available in the registry. Another option would be to specify which dependencies we need, as James wisely pointed out: ... Collection crapDependencies = new ArrayList(); crapDependencies.add(new DependencyDescriptor(WiseService.class, "wiseService", "wiseServiceId"); crapDependencies.add(new DependencyDescriptor(BillService.class, "killer", "blackMamba"); registry.inejectDependencies(myCrap, crapDependencies.toArray(new DependencyDescriptor[crapDependencies.size()]); This would inject th "wiseServiceId" service by calling myCrap.setWiseService(), and the "blackMamba" service by calling myCrap.setKiller(). I know I just repeated what everyone said above ;) I just thought that Howard didn't get it, and now I tried to explain more througly what we want, the motivation and some fictious code. I hope this helps to makes things clearer. -- Marcus Brito <[EMAIL PROTECTED]> On Wed, 27 Oct 2004 07:57:48 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > 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?) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
