My be I'm wrong because Guillaume Nodet provides an interesting answer for a previous thread: *Object: Bundle is not compatible with this blueprint extender* *Message: Such a problem is not really a problem ;-) One possible reason is that you have multiple blueprint extenders deployed (so multiple blueprint specs exported). An extender will only manage the blueprint bundles that are compatible (i.e. it imports the exact same package) as the extender. The main reason is to allow multiple blueprint implementations to co-exist. If you want to force the use of a given blueprint, one way is to make sure your blueprint bundle import a package which is specific to your extender, such as org.apache.aries.blueprint package in addition to the org.osgi.service.blueprint which should always be imported by blueprint bundles. The osgi framework will then be forced to wire against the aries api, making sure the bundle will be extended only by aries*
So It could be possible that without my patch it is perfectly working. I will try tomorrow this solution and validate that there is no double processing. Regards, Romain 2012/6/20 Romain Gilles <[email protected]> > It the night for me know, I will give you my patch tomorrow. > Is it ok for you? > You will have to checkout the tag 1.0.1.M01 from the eclipse git > repository. > > Romain. > > 2012/6/20 Anthony Bargnesi <[email protected]> > >> Romain, >> >> I believe I am seeing the initial scan problems with gemini-blueprint. >> >> The solution sounds good given the constraints. Could you share the >> patch? >> >> -tony >> >> On Wed, Jun 20, 2012 at 5:23 PM, Romain Gilles >> <[email protected]>wrote: >> >>> On my side I have done something to support Aries and Gemini-Blueprint >>> at the same time. >>> I don't remember if the enterprise specification allow 2 implementation >>> of Blueprint at the same time. But one of the issue as soon as you are >>> installing gemini-blueprint it try to scan all the bundle already >>> installed. Therefore it replay the film that Aries already does. I don't >>> know if it is a problem or not but for me in my case yes. >>> So I have added a property to gemini-blueprint to disable is blueprint >>> feature and only activate is historical spring ready bundles. >>> And it is work well in this case Aries handles the pure blueprint >>> bundles and gemini handle the pure spring bundles they can of course share >>> services. But I think at the end of the day we have to provide a distrib of >>> karaf that run on the top of blueprint. >>> >>> If the community want it, I can share my patch. I'm currently working >>> with the blueprint community to propose then this option but I'm not sure >>> they will accept it. >>> >>> Regards, >>> >>> Romain. >>> >>> 2012/6/20 Achim Nierbeck <[email protected]> >>> >>>> Just one side note :) >>>> >>>> afaik gemini 1.0 doesn't support Spring 3.1.1, you probably need also >>>> need a never version of gemini. >>>> >>>> regards, Achim >>>> >>>> 2012/6/20 Anthony Bargnesi <[email protected]>: >>>> > Hi guys, >>>> > >>>> > I'm familiar with the work done in KARAF-928 >>>> > (https://issues.apache.org/jira/browse/KARAF-928) >>>> > to support gemini-blueprint as a feature, however it is targeted for >>>> > 3.0.0-SNAPSHOT. >>>> > >>>> > I'm looking to run spring 3.1.1 + gemini blueprint 1.0.0 in karaf >>>> 2.2.7. >>>> > >>>> > I have tried installing the gemini-blueprint feature using >>>> 3.0.0-SNAPSHOT >>>> > and received NoSuchFieldError stacktraces. >>>> > Attached as exception3.0.0.log. >>>> > >>>> > If I use the spring 3.1.1 / gemini blueprint features from >>>> 3.0.0-SNAPSHOT in >>>> > 2.2.7 I have a wiring >>>> > problem: >>>> > >>>> > karaf@root> feature:install gemini-blueprint >>>> > Error executing command: Could not start bundle >>>> > >>>> mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/3.0.0-SNAPSHOT >>>> > in feature(s) spring-3.1.1.RELEASE: Unresolved constraint in bundle >>>> > org.apache.karaf.deployer.spring [70]: Unable to resolve 70.0: missing >>>> > requirement [70.0] package; >>>> > (&(package=org.osgi.framework)(version>=1.6.0)(!(version>=2.0.0))) >>>> > >>>> > What would the best course of action be? >>>> > >>>> > Thanks, >>>> > Anthony Bargnesi >>>> >>>> >>>> >>>> -- >>>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>> Committer & Project Lead >>>> OPS4J Pax for Vaadin >>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >>>> Lead >>>> blog <http://notizblog.nierbeck.de/> >>>> >>> >>> >> >
