The first time I used built a WAB I spent some time going quietly insane because I was using DS (of course) and I ended up with two instances of my service object, one created by DS and one by the WS container. That was an easy one - kill the WAB - but in general I think there will always be problems if two component frameworks are trying to control the same bundle (and potentially to instantiate the same components). Between DS/Blueprint/iPOJO it could maybe be made to work by agreeing on some common APIs, but if the other framework is WS, CDI or whatever then forget it.
>> From: Raymond Auge <raymond.a...@liferay.com> >> BJ bundles are not limited to using only a single spec! OSGi is >> modular after all, no? > >> It's entirely possible for a bundle to use several extenders at >> once. This is a completely legitimate use case. > >> This is exactly the case I'm dealing with. > >> I don't think what I'm asking is outlandish. > > It is a case discussed in the OSGi EGs and that we never agreed to solve. > Basically, we don't support multiple "active" extenders like DS, Blueprint > and Web Application Specification each trying to control a bundle. There > is no way to coordinate that as you see. We certainly expect different > bundles to use different technologies, but did not do anything to support > a single bundle to be extended by multiple active extenders. What you are > attempting to do is outside the scope of the existing OSGi specifications. > I highly recommend you split the bundle up so that only a single active > extender is controlling each bundle. > > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > hargr...@us.ibm.com > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
