You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "Roll, Kevin" <Ke...@idexx.com> on 2015/05/21 17:04:20 UTC
javax.activation
I have built an OSGi bundle that uses Apache CXF (I embedded the dependency in my bundle). I encountered a very strange error:
java.lang.LinkageError: loader constraint violation: when resolving overridden method "org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller.addMtomAttachment(Ljavax/activation/DataHandler;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;" the class loader (instance of org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentMarshaller, and its superclass loader (instance of <bootloader>), have different Class objects for the type org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller.addMtomAttachment(Ljavax/activation/DataHandler;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; used in the signature
at org.apache.cxf.jaxb.JAXBDataBase.getAttachmentMarshaller(JAXBDataBase.java:82)
After puzzling through it for a while I determined that the class javax.activation.DataHandler was the problem; it's being loaded from the Sling bundle by one classloader, and from the JRE by the other. The javax.activation package is now included as part of the JRE so I am not sure why the Sling bundle is included. I figured I would just exclude it:
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-launchpad-plugin</artifactId>
<version>2.3.2</version>
...
<bundleExclusions>
<bundle>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.javax.activation</artifactId>
<version>0.1.0</version>
</bundle>
</bundleExclusions>
</configuration>
</plugin>
This knocked out the bundle correctly but my own bundle could no longer resolve javax.activation. I find this odd as it is explicitly called out in the default Felix configuration at http://svn.apache.org/viewvc/felix/trunk/framework/src/main/resources/default.properties?view=markup as a system package that should be exported. So, I added it to my own sling_install.properties:
org.osgi.framework.system.packages.extra=javax.activation
This solved the problem and I was able to see that my bundle imported the package from the JRE. My code runs now but I wanted to bring this situation to someone's attention.
RE: javax.activation
Posted by Stefan Seifert <ss...@pro-vision.de>.
an alternative without changing the sling properties file should be:
instead of
org.apache.sling/org.apache.sling.javax.activation/0.1.0
deploy
org.apache.sling/org.apache.sling.fragment.activation/1.0.2
see https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/framework-extension-activation
stefan
>-----Original Message-----
>From: Roll, Kevin [mailto:Kevin-Roll@idexx.com]
>Sent: Thursday, May 21, 2015 5:04 PM
>To: users@sling.apache.org
>Subject: javax.activation
>
>I have built an OSGi bundle that uses Apache CXF (I embedded the dependency in
>my bundle). I encountered a very strange error:
>
>java.lang.LinkageError: loader constraint violation: when resolving overridden
>method
>"org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller.addMtomAttachment(Lja
>vax/activation/DataHandler;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Str
>ing;" the class loader (instance of
>org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the
>current class, org/apache/cxf/jaxb/attachment/JAXBAttachmentMarshaller, and
>its superclass loader (instance of <bootloader>), have different Class objects
>for the type
>org.apache.cxf.jaxb.attachment.JAXBAttachmentMarshaller.addMtomAttachment(Ljav
>ax/activation/DataHandler;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Stri
>ng; used in the signature
> at
>org.apache.cxf.jaxb.JAXBDataBase.getAttachmentMarshaller(JAXBDataBase.java:82)
>
>After puzzling through it for a while I determined that the class
>javax.activation.DataHandler was the problem; it's being loaded from the Sling
>bundle by one classloader, and from the JRE by the other. The javax.activation
>package is now included as part of the JRE so I am not sure why the Sling
>bundle is included. I figured I would just exclude it:
>
>
><plugin>
> <groupId>org.apache.sling</groupId>
> <artifactId>maven-launchpad-plugin</artifactId>
> <version>2.3.2</version>
>
> ...
> <bundleExclusions>
> <bundle>
> <groupId>org.apache.sling</groupId>
> <artifactId>org.apache.sling.javax.activation</artifactId>
> <version>0.1.0</version>
> </bundle>
> </bundleExclusions>
> </configuration>
></plugin>
>
>This knocked out the bundle correctly but my own bundle could no longer
>resolve javax.activation. I find this odd as it is explicitly called out in
>the default Felix configuration at
>http://svn.apache.org/viewvc/felix/trunk/framework/src/main/resources/default.
>properties?view=markup as a system package that should be exported. So, I
>added it to my own sling_install.properties:
>
>
>org.osgi.framework.system.packages.extra=javax.activation
>
>This solved the problem and I was able to see that my bundle imported the
>package from the JRE. My code runs now but I wanted to bring this situation to
>someone's attention.