Purportedly Spring DM allows it if it's declared as optional when using the cardinality property. Alas, it did not work for me.
Kirk Knoernschild http://www.kirkk.com http://techdistrict.kirkk.com http://planet.kirkk.com twitter: pragkirk On Aug 26, 2010, at Aug 26, 11:26 AM, 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: > > <?xml version="1.0" encoding="UTF-8"?> > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";> > <bean class="privatepackage.Interface1Impl" init-method="init" > id="bean1"> > <property name="thing" ref="ref1"></property> > </bean> > <bean class="privatepackage.Interface2Impl" id="bean2"></bean> > <service ref="bean1" interface="publicpackage.Interface1"></service> > <service ref="bean2" interface="publicpackage.Interface2"></service> > <reference id="ref1" interface="publicpackage.Interface2" > availability="optional"> > </reference> > </blueprint> > > 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 <[email protected]> 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]
