But, doesn't that potentially cause a problem? What if another module declares a service point with the same service interface unbeknownst to you and that module is added to the registry at runtime? Without that other module, my module will work. With that other module, my module will not. It would be better if it attempted to autowire WITHIN my module first, thereby taking care of my dependency. Then, when it tries to autowire within the rest of the registry, it would see that my dependency is already injected and bypass it. Does that sound reasonable?
-----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 4:48 PM To: [email protected] Subject: Re: Simple Bean injection BuilderFactory autowires all the setters of the implementation it finds a service with the matching interface for; irrespective of what module contributes that service. If there's more than one or no matching service then none is wired and an error is reported. --knut On Wed, 27 Oct 2004 16:01:03 -0400, James Carman <[EMAIL PROTECTED]> wrote: > Does it attempt to autowire first within the declaring module? > > > > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 27, 2004 3:36 PM > To: [email protected] > Subject: Re: Simple Bean injection > > 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? > > --------------------------------------------------------------------- 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]
