Community
Participate
Working Groups
Blueprint core contains org.osgi.framework.blueprint.* classes which are not exported. Blueprint extender bundle optionally imports org.osgi.framework.blueprint.* packages. Deploying the osgi.enterprise bundle with blueprint can lead to class consistency issues (see stack below) as discovered when deploying Blueprint with DB Access and the osgi.enterprise bundle. Blueprint core should import and export the org.osgi.framework.blueprint.* packages it contains so that, if present, the osgi.enterprise bundle will be used as the source of the org.osgi.framework.blueprint.* packages. Exception in thread "SpringOsgiExtenderThread-1" java.lang.NoClassDefFoundError: org/eclipse/gemini/blueprint/blueprint/container/SpringBlueprintContainer at org.eclipse.gemini.blueprint.extender.internal.blueprint.activator.BlueprintContainerProcessor.createBlueprintContainer(BlueprintContainerProcessor.java:243) at org.eclipse.gemini.blueprint.extender.internal.blueprint.activator.BlueprintContainerProcessor.preProcessRefresh(BlueprintContainerProcessor.java:162) at org.eclipse.gemini.blueprint.extender.internal.activator.LifecycleManager$1.run(LifecycleManager.java:220) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ClassNotFoundException: org.eclipse.gemini.blueprint.blueprint.container.SpringBlueprintContainer at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 4 more
In some cases an exception isn't thrown but instead you get a message like: INFO: Bundle Example is not type compatible with extender gemini-blueprint-extender (Incubation); ignoring bundle...
Correction, the Blueprint core bundle does in fact export org.osgi.service.blueprint.* packages. The lack of import is the issue. Also note that the packages in question are under org.osgi.service.blueprint, not org.osgi.framework.blueprint as I wrote in the initial bug description.
Created attachment 206907 [details] remove org.osgi classes from core The attached patch should fix this issue: - Adds a dependency on org.osgi.enterprise 4.2.0 (maven central) - removed org.osg.* packages from blueprint-core - changed template.mf, s.t. the import-package statements are correct - changed one test at 3 places where obviously some blueprint.reflect interface changed (Please verify that the solution is still correct) I actually commented out the jarjar plugin from the root manifest to be able to build. What exactly is its purpose and where can it be obtained from?
(In reply to comment #3) > Created attachment 206907 [details] > remove org.osgi classes from core > > The attached patch should fix this issue: > - Adds a dependency on org.osgi.enterprise 4.2.0 (maven central) > - removed org.osg.* packages from blueprint-core > - changed template.mf, s.t. the import-package statements are correct > - changed one test at 3 places where obviously some blueprint.reflect > interface changed (Please verify that the solution is still correct) > > I actually commented out the jarjar plugin from the root manifest to be able > to build. What exactly is its purpose and where can it be obtained from? Thanks for the patch Magnus, but it's larger than is strictly necessary to fix the bug.
Careful analysis of the org.osgi.* package exports is necessary. I'll add a separate comment for each bundle. The core bundle exports: org.osgi.service.blueprint.container;version="1.0.0";uses:="org.osgi.framework,org.osgi.service.blueprint.reflect", org.osgi.service.blueprint.reflect;version="1.0.0" and imports these with suitable version ranges: org.osgi.service.blueprint.container;version="[1.0.0,1.1)", org.osgi.service.blueprint.reflect;version="[1.0.0,1.1)" NB. the exclusive upper bound of 1.1 is necessary as Gemini Blueprint implements these interfaces. See "Importer Policy" in the semantic versioning white paper for the rationale: http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf.
The extender bundle exports (since bug 351755 was fixed - a few minutes ago): org.osgi.service.blueprint;version="1" Now the OSGi enterprise 5.0 companion JAR (apparently intended for compilation only rather than runtime, but let's overlook that for our current purposes) exports the following: org.osgi.service.blueprint.reflect;version="1.0.1", org.osgi.service.blueprint.container;uses:="org.osgi.service.blueprint.reflect,org.osgi.framework";version="1.0.2" It makes no mention of the package org.osgi.service.blueprint and so there is no need for the extender to import that package in order to co-exist with the OSGi enterprise JAR. Also, it is not clear that a substitutable export would be appropriate for this particular package as it is special purpose and contains no classes. See bug 351755 for details plus a reference to the OSGi spec.
For the record, note that the OSGi enterprise 4.2 companion JAR exports the following: org.osgi.service.blueprint.reflect;version="1.0.1", org.osgi.service.blueprint.container;uses:="org.osgi.service.blueprint.reflect,org.osgi.framework";version="1.0.1" and imports the following: org.osgi.service.blueprint.container;resolution:=optional;version="[1.0,2)", org.osgi.service.blueprint.reflect;resolution:=optional;version="[1.0,2)" so neither does this mention the package org.osgi.service.blueprint, further justifying the decision not to import that package in the extender bundle.
The io bundle neither exports nor imports any org.osgi.* packages and therefore does not need changing.
Since the problem is not present at master (destined for the 2.0 release), I checked back levels to see where the bug exists. The bug is present in Gemini Blueprint 1.0.0.RELEASE, but is fixed in 1.0.1.RELEASE (and 1.0.2.RELEASE).
*** This bug has been marked as a duplicate of bug 385307 ***
