I don't think it really muddles the principles at all. If you have a service implementation declared in your module which requires a DataSource and you declare a service point in your module which implements DataSource, I would think that you would want your service implementation to be wired to that one. And you wouldn't want your module to break when another module comes along, which declares another service point implementing DataSource. If anything, this strategy will save you some typing in your module descriptor. I don't think it breaks anything, really. Worst case, you could still do exactly what you said, and use the <set-service> for the problematic dependencies. But, you wouldn't have to if you really did want to use the one from your module (I can't see it happening any other way, realistically).
-----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 5:39 PM To: HiveMind Dev List Subject: Re: Simple Bean injection 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
