Tim, That is an alternative solution I tried. But I didn't use a listener and so it had a pretty bad smell.
Essentially what I did was that when Bundle C started, it got a reference to the Interface2 service that was backed by the Interface2Impl2 class and I injected that into the client which it turned called the set method on the Interface1 service. That just didn't seem right. Is there a way to use the listener approach you describe below and swap out the default implementation bean (Interface2Impl1) with the service (Interface2Impl2) via blueprint configuration? Or at least create a listener class that gets invoked when the Interface2 service backed by Interface2Impl2 is registered, but where the listener class is not dependent on the OSGi framework? Kirk Knoernschild http://www.kirkk.com http://techdistrict.kirkk.com http://planet.kirkk.com twitter: pragkirk On Aug 26, 2010, at Aug 26, 12:43 PM, Timothy Ward wrote: > > I would like to ask, why would you expose a service to provide a default > implementation within a bundle? The default implementation bean can be wired > in directly using blueprint, and a listener can be used to switch in the > optional "replacement service" if it becomes available. The default service > can still be exposed in the service registry for use by other bundles. > > Regards, > > Tim > > ---------------------------------------- >> Subject: Re: Spring DM/Blueprint Services >> From: [email protected] >> Date: Thu, 26 Aug 2010 12:37:53 -0500 >> To: [email protected] >> >> Ah yes. The same phrase is found in the Spring DM documentation, and now I >> see it's also in the blueprint spec. Thank you for pointing that out. >> >> So in general, my design below is not supported. However, I don't perceive >> it as a design flaw. >> >> It seems reasonable that a bundle would define a default implementation for >> one of it's services where that service is also used by that bundle. It also >> seems reasonable that I might want to change the implementation at runtime >> so that the bundle now uses a different implementation of that service. I >> can easily do that if I separate it all out into separate bundles. >> >> Like this: >> Bundle A - Interface1, Interface1Impl (uses Interface2 service) >> Bundle A1- Interface2, Interface2Impl1 >> Bundle A2 - Interface2Impl2 >> >> Bundle C - uses Interface1service >> >> Upon deploying Bundle A and Bundle A1, Bundle C will use Interface1 with the >> default Interface2Impl1 that backs Interface2. I can stop Bundle A1, deploy >> and start Bundle A2 and now Bundle C uses Interface1 with the new >> Interface2Impl2 that backs Interface2. Works fine. >> >> However, if I eliminate Bundle A1 and put those classes in Bundle A, it >> doesn't work. Foremost, it doesn't work because the spec doesn't allow it. >> But also, since the service lifecycle is tied to the bundle lifecycle, I >> suppose I wouldn't be able to easily substitute Interface1Impl1 with >> Interface2Impl2. But that is what I would prefer because the approach that >> works seem to cause an unnecessary proliferation of bundles. >> >> At least, that is what I'm seeing. Which is why I'm wondering if I'm missing >> an alternative solution. >> >> Kirk Knoernschild >> http://www.kirkk.com >> http://techdistrict.kirkk.com >> http://planet.kirkk.com >> twitter: pragkirk >> >> >> >> >> On Aug 26, 2010, at Aug 26, 11:40 AM, Mark Nuttall wrote: >> >>> Enterprise 4.2 spec, section 121.7.9: >>> >>> "It is an error to declare a mandatory reference to a service that is >>> registered by the same bundle. Such >>> a definition could cause either deadlock or a timeout." >>> >>> Regards, >>> Mark >>> >>> On 26 August 2010 17:26, Alasdair Nottingham wrote: >>>> Hi, >>>> >>>> I can't comment on Spring DM, because I don't have any experience >>>> there, but if you use blueprint it can be possible if you define the >>>> reference to have an optional availability for example: >>>> >>>> >>>> >>>> >>>> id="bean1"> >>>> >>>> >>>> >>>> >>>> >>>> >>>> availability="optional"> >>>> >>>> >>>> >>>> Having run this through the init method of Interface1Impl has the >>>> reference injected by the time it is called, but of course this isn't >>>> necessarily safe to assume. >>>> >>>> I'm going to head back to the blueprint spec to see if this cycle is >>>> prohibited from working for a mandatory reference, but if it isn't >>>> I'll raise a JIRA to allow this type of cycle. >>>> >>>> Alasdair >>>> >>>> On 26 August 2010 16:17, Kirk Knoernschild wrote: >>>>> I've been using Spring DM, and one thing that I'm struggling with is that >>>>> a bundle that exports a service is unable to use that service. This seems >>>>> to be a feasible design option, and I'm wondering what others have done >>>>> to work around it. >>>>> >>>>> For instance, let's say I have three bundles. >>>>> >>>>> BundleA with Interface1, Interface2, Interface1Impl, and Interface2Impl1. >>>>> BundleB with Interface2Impl2 >>>>> BundleC with ClassC that uses Interface1. >>>>> >>>>> On start, BundleA registers two new services Interface1Service and >>>>> Interface2Service, using Interface1Impl and Interface2Impl1 as their >>>>> implementations, respectively. As it happens, the Interface1Impl requires >>>>> an Interface2 type, so using Spring DM, I've tried injecting the >>>>> Interface2 service into the Interface1 service. It doesn't work because >>>>> Spring DM doesn't allow a bundle to use a service it registers, so I >>>>> inject it as a regular bean. >>>>> >>>>> I want to do this because I install BundleB and register another >>>>> Interface2Service service, now using Interface2Impl2. Because I cannot >>>>> inject the service backed by Interface2Impl1 into the service backed by >>>>> Interface1Impl, the service backed by Interface1Impl won't be able to use >>>>> Interface2Impl2. >>>>> >>>>> FWIW, I can move Interface2 and Interface2Impl1 to a separate bundle and >>>>> register it as a service. That does work, but it's not the application >>>>> structure I want. >>>>> >>>>> Possibly there is an alternative design to this that is more suitable to >>>>> this situation. I'm just not sure what that is at this point. Any >>>>> suggestions are appreciated. >>>>> >>>>> I can send code if it would be helpful to illustrate this. >>>>> >>>>> Kirk Knoernschild >>>>> http://www.kirkk.com >>>>> http://techdistrict.kirkk.com >>>>> http://planet.kirkk.com >>>>> twitter: pragkirk >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Alasdair Nottingham >>>> [email protected] >>>> >> >
