To be clear, the visibility doesn't limit auto-wiring to just services in a given module. From within a module, it allows wiring to visible services in any module.
The methods on Registry will only "see" public services (in any module). On Wed, 27 Oct 2004 12:23:38 -0400, James Carman <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
