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 <stephan.si...@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
dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog
<http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>
