You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by "Siano, Stephan" <st...@sap.com> on 2019/01/31 12:30:59 UTC
Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Hi,
We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
The root cause for this was the following.
With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
at javax.activation.DataHandler.getContent(DataHandler.java:142)
at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
Best regards
Stephan
RE: Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Posted by "Siano, Stephan" <st...@sap.com>.
Hi Daniel,
I am not completely sure who actually loads this class, but this class is actually available from anywhere because of bootdelegation for com.sun.*... I have not figured out how to exclude something from bootdelegation (like everything starting with com.sun. except packages starting with com.sun.xml.internal.messaging...)
I also think that this is a bug in the saaj-impl 1.3.28 bundle, the issue is fixed in 1.4.0 and later.
Best regards
Stephan
-----Original Message-----
From: Daniel Kulp <dk...@apache.org>
Sent: Donnerstag, 31. Januar 2019 14:18
To: dev@karaf.apache.org
Subject: Re: Interdependencies between SAAJ, Activation, and javamail on karaf 4.2.3/karaf 4.2.2
My question:
How is saaj-impl:1.3.28_1 accessing com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler ? Shouldn’t the “internal” classes not be exported from the system? Looking at the MANIFEST, it doesn’t seem to be importing it either.
That said, this looks like a bug in SAAJ-IMPL. Saaj-impl contains all those classes, it should be registering it’s own versions, not the “internal” versions. The code:
public static void initializeJavaActivationHandlers() {
// DataHandler.writeTo() may search for DCH. So adding some default ones.
try {
CommandMap map = CommandMap.getDefaultCommandMap();
if (map instanceof MailcapCommandMap) {
MailcapCommandMap mailMap = (MailcapCommandMap) map;
// registering our DCH since javamail's DCH doesn't handle
if (!cmdMapInitialized(mailMap)) {
mailMap.addMailcap("text/xml;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.XmlDataContentHandler");
mailMap.addMailcap("application/xml;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.XmlDataContentHandler");
mailMap.addMailcap("application/fastinfoset;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.FastInfosetDataContentHandler");
//mailMap.addMailcap("multipart/*;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.MultipartDataContentHandler");
mailMap.addMailcap("image/*;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.ImageDataContentHandler");
mailMap.addMailcap("text/plain;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler");
}
}
} catch (Throwable t) {
// ignore the exception.
}
}
Seems like the “internal” should be stripped from that. Kind of wonder if the shade plugin can be used to fix that or not. Hmm….
Dan
> On Jan 31, 2019, at 7:30 AM, Siano, Stephan <st...@sap.com> wrote:
>
> Hi,
>
> We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
>
> The root cause for this was the following.
>
> With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
>
> As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
>
> The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
>
> Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
>
> java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
> at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
> at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
> at javax.activation.DataHandler.getContent(DataHandler.java:142)
> at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
> at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
>
> The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
> com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
>
> Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
>
> Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
>
> Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
>
> Best regards
> Stephan
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Posted by Daniel Kulp <dk...@apache.org>.
My question:
How is saaj-impl:1.3.28_1 accessing com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler ? Shouldn’t the “internal” classes not be exported from the system? Looking at the MANIFEST, it doesn’t seem to be importing it either.
That said, this looks like a bug in SAAJ-IMPL. Saaj-impl contains all those classes, it should be registering it’s own versions, not the “internal” versions. The code:
public static void initializeJavaActivationHandlers() {
// DataHandler.writeTo() may search for DCH. So adding some default ones.
try {
CommandMap map = CommandMap.getDefaultCommandMap();
if (map instanceof MailcapCommandMap) {
MailcapCommandMap mailMap = (MailcapCommandMap) map;
// registering our DCH since javamail's DCH doesn't handle
if (!cmdMapInitialized(mailMap)) {
mailMap.addMailcap("text/xml;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.XmlDataContentHandler");
mailMap.addMailcap("application/xml;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.XmlDataContentHandler");
mailMap.addMailcap("application/fastinfoset;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.FastInfosetDataContentHandler");
//mailMap.addMailcap("multipart/*;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.MultipartDataContentHandler");
mailMap.addMailcap("image/*;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.ImageDataContentHandler");
mailMap.addMailcap("text/plain;;x-java-content-handler=com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler");
}
}
} catch (Throwable t) {
// ignore the exception.
}
}
Seems like the “internal” should be stripped from that. Kind of wonder if the shade plugin can be used to fix that or not. Hmm….
Dan
> On Jan 31, 2019, at 7:30 AM, Siano, Stephan <st...@sap.com> wrote:
>
> Hi,
>
> We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
>
> The root cause for this was the following.
>
> With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
>
> As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
>
> The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
>
> Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
>
> java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
> at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
> at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
> at javax.activation.DataHandler.getContent(DataHandler.java:142)
> at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
> at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
>
> The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
> com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
>
> Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
>
> Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
>
> Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
>
> Best regards
> Stephan
--
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
SMX Bundles release is expected by the end of this week.
Regards
JB
On 31/01/2019 14:09, Siano, Stephan wrote:
> Hi Jean-Baptiste,
>
> Thanks a lot! At least in theory this should work. Do you have an idea when this will be released?
>
> Just out of curiosity: Is this related to the upcoming Karaf 4.2.3 release or is that completely unrelated?
>
> Best regards
> Stephan
>
> -----Original Message-----
> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
> Sent: Donnerstag, 31. Januar 2019 13:44
> To: dev@karaf.apache.org
> Subject: Re: Interdependencies between SAAJ, Activation, and javamail on karaf 4.2.3/karaf 4.2.2
>
> Hi Stephen,
>
> I'm also planning to release saaj-impl 1.4.x bundle with a version
> range, I guess it will help.
>
> Regards
> JB
>
> On 31/01/2019 13:30, Siano, Stephan wrote:
>> Hi,
>>
>> We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
>>
>> The root cause for this was the following.
>>
>> With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
>>
>> As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
>>
>> The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
>>
>> Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
>>
>> java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
>> at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
>> at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
>> at javax.activation.DataHandler.getContent(DataHandler.java:142)
>> at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
>> at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
>>
>> The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
>> com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
>>
>> Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
>>
>> Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
>>
>> Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
>>
>> Best regards
>> Stephan
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Posted by "Siano, Stephan" <st...@sap.com>.
Hi Jean-Baptiste,
Thanks a lot! At least in theory this should work. Do you have an idea when this will be released?
Just out of curiosity: Is this related to the upcoming Karaf 4.2.3 release or is that completely unrelated?
Best regards
Stephan
-----Original Message-----
From: Jean-Baptiste Onofré <jb...@nanthrax.net>
Sent: Donnerstag, 31. Januar 2019 13:44
To: dev@karaf.apache.org
Subject: Re: Interdependencies between SAAJ, Activation, and javamail on karaf 4.2.3/karaf 4.2.2
Hi Stephen,
I'm also planning to release saaj-impl 1.4.x bundle with a version
range, I guess it will help.
Regards
JB
On 31/01/2019 13:30, Siano, Stephan wrote:
> Hi,
>
> We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
>
> The root cause for this was the following.
>
> With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
>
> As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
>
> The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
>
> Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
>
> java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
> at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
> at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
> at javax.activation.DataHandler.getContent(DataHandler.java:142)
> at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
> at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
>
> The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
> com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
>
> Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
>
> Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
>
> Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
>
> Best regards
> Stephan
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Interdependencies between SAAJ, Activation, and javamail on karaf
4.2.3/karaf 4.2.2
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Stephen,
I'm also planning to release saaj-impl 1.4.x bundle with a version
range, I guess it will help.
Regards
JB
On 31/01/2019 13:30, Siano, Stephan wrote:
> Hi,
>
> We are building a custom distribution currently based on Karaf 4.2.2 (but including some changes from Karaf 4.2.3) which is running on Java 8. We have observed that once we are sending a SOAP message with attachments via CXF, javamail will stop working.
>
> The root cause for this was the following.
>
> With the changes from [KARAF-5989] and [KARAF-6093] the javax.activation and the javax.xml.soap are removed from the Java 8 section from jre.properties.
>
> As a consequence the bundles org.apache.servicemix.specs:org.apache.servicemix.specs.activation-api-1.1:2.9.0 and org.apache.servicemix.specs: org.apache.servicemix.specs.saaj-api-1.3:2.9.0 are installed in the stack. In order to make CXF work the bundle org.apache.servicemix.bundles:org.apache.servicemix.bundles.saaj-impl:1.3.28_1 is also added to the stack.
>
> The servicemix wrapped activation api bundle has an OSGi enabled registry for MIME DataTypeHandlers, where javamail registers some data type handlers (among others for text/plain via mailcap file). In addition javamail wires the javax.activation package wth this bundle. So far everything works.
>
> Unfortunately the constructor of com.sun.xml.messaging.saaj.soap.AttachmentPartImpl contained in the saaj-impl bundle (in version 1.3.28_1) registers com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler as a data content handler for text/plain. This class is coming from the JDK and implements javax.activation.DataContentHandler from JDK. If after this registration javamail tries to look up a DataContentHandler for text/plain, the registry in the javax.activation api bundle will contain that handler but as the bundles has its own version of javax.activationDataContentHandler, we will get a ClassCastException:
>
> java.lang.ClassCastException - com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)]java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.StringDataContentHandler cannot be cast to javax.activation.DataContentHandler (loaded by org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8) (found matching interface javax.activation.DataContentHandler loaded by , but needed loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x0000000100162fd8)
> at com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179)
> at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249)
> at javax.activation.DataHandler.getContent(DataHandler.java:142)
> at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454)
> at org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601)
>
> The culprit seems to be the saaj-impl bundle. So I looked for newer version. There is a version 1.4.0_1 that is actually registering DataContentHandlers like
> com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the internal), which is instead coming from the saaj-api bundle (which wires with the javax.activation bundle in the stack), so this should work. Unfortunately the version 1.4.0 imports package version 1.4 or later of package javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of that package.
>
> Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the servicemix bundles repository, though I don't know why he did so and when he plans to release that version.
>
> Are you already aware of this or is this change not related to the Karaf 4.2.3 release at all?
>
> Does anyone know any combination of saaj/saaj-impl OSGi bundles that work with Java 8 on Karaf?
>
> Best regards
> Stephan
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com