Yes, it does cause the problem you describe. From the documentation on
BuilderFactory:
"Autowiring may be complicated by the fact that one module may
define a service point that will tangentially affect the construction
of a service in another module (simply by implementing the same
service interface). In this situation, service autowiring can be
turned off, by setting the autowire-services attribute to false."
In my experience the cases where this problem could arise are known in
beforehand. E.g. a DataSource. In those cases autowiring can be
disabled. Or I think you should also be able to "prophylactically"
protect your services against clashes of this kind by leaving
autowiring enabled *and* using explicit <set-service> elements for the
problematic services. The autowiring should ignore those.
That said I still think your approach sounds reasonable. It would be
a different dependency injection strategy. (This would IMO again
favor providing a configurable ServiceInjector :-) But somehow I
still get the feeling that this approach would muddle the principles
behind HiveMind.
--knut
On Wed, 27 Oct 2004 16:55:12 -0400, James Carman
<[EMAIL PROTECTED]> wrote:
> 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]
