I have two OSGI bundles(base, dependent), dependent bundle accessing some API of base bundle. When I undeploy base bundle and redeploy it I am getting "Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.base-1.0.jar".main is already registered", however undeployment of base bundle was successful.
I want to understand how undeployment of osgi bundle works when there are couple of bundles dependent on it.
Base Bundle Manifest
Manifest-Version: 1.0
Bundle-Activator: com.learning.base.BaseBundleActivator
Bundle-Category: osgi
Bundle-ManifestVersion: 2
Bundle-Name: base
Bundle-SymbolicName: OSGI.base
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: org.osgi.framework;version="1.7",com.learning.base.model;version="1.0.0",com.learning.base.service;version="1.0.0";uses:="com.learning.base.model"
Import-Package: com.learning.base.model;version="[1.0,2)",com.learning.base.service;version="[1.0,2)",javax.security.auth.x500,org.osgi.framework;version="[1.7,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
Dependent Bundle Manifest
Manifest-Version: 1.0
Bundle-Activator: com.learning.dependent.DependentBundleActivator
Bundle-Category: osgi
Bundle-Name: dependent
Bundle-SymbolicName: OSGI.dependent
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: com.learning.dependent.model;version="1.0.0";uses:="com.learning.base.model",com.learning.dependent.service;version="1.0.0";uses:="com.learning.dependent.model,org.osgi.framework"
Import-Package: org.osgi.framework;version="[1.7,2)",com.learning.base.model;version="[1.0,2)",com.learning.base.service;version="[1.0,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
Related
Plugin version: 3.3.0
I am wondering how maven-bundle-plugin resolves the version from duplicated Export-Packages bundle, the following is from mvn -X debug output and seems like the plugin is using the version from the first bundle found.
-----------------------------------------------------------------------
[DEBUG] BND Classpath:
-----------------------------------------------------------------------
-classpath:\ D:\dev\m3repo\io\dropwizard\metrics\metrics-core\3.1.2\metrics-core-3.1.2.jar,\
D:\dev\m3repo\com\codahale\metrics\metrics-core\3.0.2\metrics-core-3.0.2.jar
-----------------------------------------------------------------------
MANIFEST.MF (io\dropwizard\metrics\metrics-core\3.1.2\metrics-core-3.1.2.jar)
Manifest-Version: 1.0
Bnd-LastModified: 1430020731305
Build-Jdk: 1.8.0_05
Built-By: ryantenney
Bundle-Description: Metrics is a Java library which gives you unparallel ed insight into what your code does in production. Metrics provi des a powerful toolkit of ways to measure the behavior of critical
components in your production environment.
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html Bundle-ManifestVersion: 2
Bundle-Name: Metrics Core
Bundle-SymbolicName: io.dropwizard.metrics.core
Bundle-Version: 3.1.2
Created-By: Apache Maven Bundle Plugin
Export-Package: com.codahale.metrics;uses:="org.slf4j,javax.management,sun.misc";version="3.1.2"
Implementation-Title: Metrics Core
Implementation-Vendor-Id: io.dropwizard.metrics
Implementation-Version: 3.1.2
Import-Package: javax.management,org.slf4j;version="[1.6.0,2.0.0)",sun.m isc;resolution:=optional
Tool: Bnd-1.50.0
MANIFEST.MF (com\codahale\metrics\metrics-core\3.0.2\metrics-core-3.0.2.jar)
Manifest-Version: 1.0
Bnd-LastModified: 1392597083041
Build-Jdk: 1.7.0_51
Built-By: coda
Bundle-Description: Metrics is a Java library which gives you unparallel ed insight into what your code does in production. Metrics provi des a powerful toolkit of ways to measure the behavior of critical
components in your production environment.
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-ManifestVersion: 2
Bundle-Name: Metrics Core
Bundle-SymbolicName: com.codahale.metrics.core
Bundle-Version: 3.0.2
Created-By: Apache Maven Bundle Plugin
Export-Package: com.codahale.metrics;uses:="org.slf4j,javax.management,s un.misc";version="3.0.2"
Implementation-Title: Metrics Core
Implementation-Vendor-Id: com.codahale.metrics
Implementation-Version: 3.0.2
Import-Package: javax.management,org.slf4j;version="[1.6.0,2.0.0)",sun.m isc;resolution:=optional
Tool: Bnd-1.50.0
And the final output MANIFEST.MF for my bundle:
#-----------------------------------------------------------------------
[DEBUG] Final Manifest:
#-----------------------------------------------------------------------
Manifest-Version: 1.0
Bnd-LastModified: 1499834358907
Build-Jdk: 1.8.0_111
Built-By: ys03
Bundle-Description: MyBundle
Bundle-DocURL: http://my.bundle
Bundle-ManifestVersion: 2
Bundle-Name: MyBundle
Bundle-SymbolicName: com.foo.bar.myBundle
Bundle-Vendor: ysw
Bundle-Version: 1.0.0.11
Created-By: Apache Maven Bundle Plugin
Export-Package: com.foo.bar.myBundle;
Implementation-Version: 1.0.0.11 Build: dfaf45de3d27234d42fcc2841e06ccc8
ed530f18 Timestamp: 2017-07-12 12:39:12
Import-Package:
com.fasterxml.jackson.databind;version="[2.3.0,3.0.0)",
org.joda.time.format;version="[2.1.0,3.0.0)",
com.codahale.metrics;version="[3.1,4)",
com.google.common.collect;version="[19.0,20)",
org.apache.commons.codec.binary;version="[1.10,2)",
org.apache.commons.lang3;version="[3.4,4)",
org.slf4j;version="[1.7,2)",
Tool: Bnd-3.3.0.201609221906
#-----------------------------------------------------------------------
The final version for com.codahale.metrics is [3.1,4), I suppose it should be [3.0,4), please correct my understanding if I am wrong.
Thanks.
I would say the automatism uses the maven dependency you specified, and then it goes on to try resolution via the transitive dependencies. Something might be hidden in there that requires 3.1 .
It is known that any dependent plugin in a plugin gets loaded only when referenced portion (of dependent plugin) gets called up due to lazy loading concept . In that case, I have a doubt how does the dependencies in a plugin gets resolved. Is it via the name check in plugin registry ?
Platform plug-in loader checks the plug-in dependencies in MANIFEST.MF file. The content of typical MANIFEST.MF file looks like:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-SymbolicName: XXX;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: XXX
Bundle-Vendor: %Bundle-Vendor
Bundle-Localization: plugin
Eclipse-BundleShape: dir
Require-Bundle: Plugin id 1,
Plugin id 2,
Plugin id 3,
Plugin id 4
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Here Require-Bundle property lists all dependent plug-ins.
Read more about this here
Use this plugin to check dependencies.
I am developing plugin that need to use JDBC driver (mysql-connector-java-5.1.19-bin.jar). When I define path to this jar file in plugin manifest like this:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
plugin stops to recognize my view and i get this exception:
java.lang.ClassNotFoundException: diplomaproject.views.SampleView
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:326)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193)
...
When i delete line:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
from manifest, view is working but JDBC connector does not work.
My whole manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: DiplomaProject
Bundle-SymbolicName: diplomaProject; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: diplomaproject.Activator
Bundle-Vendor: MYDIPLOMA
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
You have to add a dot ('.') to the bundle class path. This adds all classes compiled from the sources contained in your plug-in to the class path.
The correct property in the manifest should be:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar,
.
You need to add the bundle to the classpath as well. Try this:
Bundle-ClassPath: .,lib/mysql-connector-java-5.1.19-bin.jar
I was facing the same problem.
My build.properties file was changed because of some changes.
I replaced the content from the similler project and it worked.
Most esteemed host of Eclipse magi ..
I am trying to create an instance of the org.eclipse.jdt.ui.wizards.NewClassWizardPage class. I have one project where I do this, and it will compile & run on Linux, but not on a Mac. Both machines are running the Helios edition of Eclipse with the PDE, both were downloaded with the last week.
The bundle org.eclipse.jdt.ui is available on the Mac, but for some reason the Mac will not compile the phrase
import org.eclipse.jdt.ui.wizards.NewClassWizardPage;
Saying "The import org.eclipse.jdt.ui.wizards.NewClassWizardPage cannot be resolved". The MANIFEST.MF is a simple one ..
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: RcpTest0
Bundle-SymbolicName: rcpTest0; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: rcptest0.Activator
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.core.resources,
org.eclipse.jdt,
org.eclipse.jdt.core,
org.eclipse.jdt.ui
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Your clues & boos are all most welcome.
Aha! The answer was that I had current versions of the JDT checked out in other projects in the workspace. They were being picked in preference over the JARs. Now to understand how I can get the PDE and JDT source bundles downloaded & installed.
In my Eclipse runtime, I have the following three plug-ins (file names simplified for better readability):
javax.wsdl.1.4.0.jar
javax.wsdl.1.5.1.jar
eclipse.wsdl.jar, which has a version restriction on the dependency: [1.4.0, 1.5.0)
The dependencies of my own plugin look like this:
eclipse.wsdl
javax.wsdl : "1.4.0"
When my own plugin tries to use the class WSDLFactory, an error would be thrown:
java.lang.LinkageError: loading constraint violation: loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader#a7b0a7b" previously initiated loading for a different type with name "javax/wsdl/factory/WSDLFactory" defined by loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader#7c647c64"
Apparently, my own plug-in loads the 1.5.1 version of WSDLFactory, while eclipse.wsdl loads the 1.4.0 version of WSDLFactory, and this cause the conflict. If I change the version restriction of my plugin to be [1.4.0, 1.5.1), the code would work just fine. However, this is unacceptable since my code needs to support Eclipse 3.5 which forces to use javax.wsdl.1.5.1 intead of 1.4.0.
Are there any way to force my code to use the WSDLFactory loaded by eclipse.wsdl instead of trying to load its own?
And if possible at all, is there a way to force loading the lowest version (instead of highest) bundle?
Update: I tried both Require-Bundle and Import-Package and got different results in dev and release environment. Require-Bundle doesn't work for either one. Import-Package works in the dev environment but not in the release environment.
My question is, while Require-Bundle would try to load classes that are in the highest version of the plugin, does Import-Package NOT behave like that?
The following are corresponding MANIFEST.MF's:
Require-Bundle:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Test
Bundle-SymbolicName: wsdl.classloading.test; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: wsdl.classloading.test.Activator
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.wst.wsdl;bundle-version="1.1.202",
javax.wsdl;bundle-version="1.4.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Import-Package:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Test
Bundle-SymbolicName: wsdl.classloading.test; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: wsdl.classloading.test.Activator
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.wst.wsdl;bundle-version="1.1.202"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Import-Package: javax.wsdl,
javax.wsdl.factory,
javax.wsdl.xml