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.