IBM Java 7 and Metro compatibility issues?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

IBM Java 7 and Metro compatibility issues?

This post has NOT been accepted by the mailing list yet.
I'm having some problems trying to get metro working with IBM Java 7.  We have a pretty goofy complicated deployment, so rather than get into the specifics of what we're trying to do, I thought I'd highlight the point issues I'm running into and see if people have any clue.

So first problem.  the IBM JDK prior to Java 7 was effectively missing the internal com.sun.org.apache.internal.* jaxp implementation.  There are numerous cases of people being suggested to download the proper jaxp version and included it JAVA_HOME/jre/lib/ext.    Prior to Java 7 this worked fine.  With java 7 the following occurs when attempting to create a SOAP envelope:
Caused by: java.lang.ClassCastException: com.sun.org.apache.xerces.internal.util.SymbolTable incompatible with org.apache.xerces.util.SymbolTable
       at org.apache.xerces.impl.XMLScanner.setProperty(Unknown Source)
       at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.setProperty(Unknown Source)
       at org.apache.xerces.impl.XMLDocumentScannerImpl.setProperty(Unknown Source)
       at org.apache.xerces.parsers.XML11Configuration.setProperty(Unknown Source)
       at org.apache.xerces.parsers.AbstractSAXParser.setProperty(Unknown Source)
       at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(Unknown Source)
       at org.apache.xerces.jaxp.SAXParserImpl.setProperty(Unknown Source)
       at com.sun.xml.messaging.saaj.util.ParserPool.resetSaxParser(ParserPool.java:116)
       at com.sun.xml.messaging.saaj.util.ParserPool.returnParser(ParserPool.java:99)
       at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:132)

ParserPool  has the following:
        factory = new com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl();
        for (int i = 0; i < capacity; i++) {
           try {

This SAXParser is assign a SymbolTable later:
            com.sun.org.apache.xerces.internal.util.SymbolTable table = new com.sun.org.apache.xerces.internal.util.SymbolTable();

the JAXP internal implementation of com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl() retruns a com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl which accepts the com.sun.org.apache.xerces.internal.util.SymbolTable class without any problems.  However as of Java 7, IBM now ships a SAXParserFactoryImpl.java that decompiles to this:
package com.sun.org.apache.xerces.internal.jaxp;

public class SAXParserFactoryImpl extends org.apache.xerces.jaxp.SAXParserFactoryImpl

This creates a org.apache.xerces.jaxp.SAXParserImpl()  in the newSAXParser() which is not compatible with the com.sun.org.apache.xerces.internal* classes.

So my first reaction is, great, IBM has a JAXP implementation that contains com.sun.org.apache.*.internal APIs.  Let's get rid of jaxp-ri.jar from the classpath.  As soon as I do this, I get a massive number of NoClassDefFoundErrors or ClassNotFoundExceptions looking for com.sun.org.apache.*.internal classes that IBM chose NOT to bundle.

I started tracking those down and some projects have over time updated their code to work and other projects have not.  for example:
was fixed some time ago for this same compatibilty problem.

So basically, i'm in a case where the ibm xml.jar is incomplete, the saaj implementation expects com.sun.org.apache.*.internal APIs and can think of only one solution to make this work.
well two:
1) stop using IBM - unfortunately this is not an option
2) -Xbootclasspath/p:[path to]/jaxp-ri.jar to make sure that the reference jaxp implementation overrides the IBM xml.jar implementation
    I have no idea what the ramifications of this are.

Has anyone else encountered similar problems trying to get metro working properly with the IBM JDK?  i initially started with metro 2.2.1 (long story, don't ask why) but similar problems exist with 2.3.1.

So far the -Xbootclasspath/p trick seems to be holding, but I haven't figured out exactly what I need to fully test against it.