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] >>> >
