Xerces and Xalan with WAS 5

[Joe Herbers]

Our application deploys and runs fine if we put our dependent jars in the
WAS's startup classpath, or if we put the jars in the "classes" dir
(dropping them into lib/ext didn't seem to have any effect - should it?).
Neither of these approaches are ideal, so we put our dependent jars into our
ear file as described in various documents (IBM and general J2EE)

This works for most of the jars, but not Xerces and Xalan. It appears that
we must have xerces.jar and xalan.jar in the classes dir in order for our
app to work. My understanding is that WAS 5.0 includes Xerces and Xalan -
what version? The versions we are deploying with are app are Xerces 1.3.0
and Xalan 2.1.0. Are WAS's newer or older?

If I don't have the jars in the classes dir or the ear, then I get
NoClassDefFoundError: org/apache/xalan/xslt/XSLTProcessorFactory If I don't
put the xalan jar in the classes dir but I do still have them in the ear, I
get IncompatibleClassChangeError. Hmm...perhaps this second issue is
because some code uses xalan classes like XSLTProcessorFactory
directly.

On a related note, the WAS docs say that you can put jars in the
"Applications Extensions" directory for automatic inclusion in the appserver
classpath. This works, and if we put Xerces and Xalan in lib/app, our app
runs fine. However, then the WAS Console won't work! This is strange since
the docs specifically mention using the Apps Ext dir to update the XML
functionality - ?

[eric_google]

"Joe Herbers" <Joe.H...@eds.com> wrote in message news:<b4529l$47ra$1...@news.boulder.ibm.com>...

We store all of our jars in a directory called app_library, so all the
applications that need to use them, can use this location. This is
where we store Xerces and Xalan. However, you need to remeber to
include this in the application class path. This can be found in your
appliction server settings on the JVM tab.

[Sandy Mustard]

Hey Joe,

BTDT.

Websphere 5 used version 4.0.9 of XML4J for xml parsing. So there is
your conflict.

Did you know that Websphere 5 changed the default classloader loading
order from parent last to parent first. Websphere 4 used parent last.

Set the parent last parameter on the classloader dialog and Websphere 5
will use the classes from the ear classpath before the jvm classpath.

Sandy Mustard

[Johan Åbrandt]

Sandy Mustard wrote:

> Hey Joe,
>
> BTDT.
>
> Websphere 5 used version 4.0.9 of XML4J for xml parsing. So there is
> your conflict.
>
> Did you know that Websphere 5 changed the default classloader loading
> order from parent last to parent first. Websphere 4 used parent last.
>
> Set the parent last parameter on the classloader dialog and Websphere 5
> will use the classes from the ear classpath before the jvm classpath.

Maybe this is not relevant, but in WAS 4 I had to add a -D switch to be
able to override xerces:

java -Dcom.ibm.ws.classloader.classSharing=false ...

I am not sure if this affects the loading order, or if it turns some
performance optimization for caching class definitions off.

[Joe Herbers]

Thanks for the suggestion, I didn't realize this, but it doesn't seem to
affect my problem. On the console, I went to the App Server entry of my
server and on the Configuration tab changed Application Class Loading Mode
to "parent last" (and change Application classloader policy to "single"
since that what the comments indicate that's when the Mode applies). If I
have the XML jars in the ear, then I still get this exception when our code
uses the xalan stuff:

java.lang.IncompatibleClassChangeError: org.apache.xpath.DOMHelper method
createDocument()Lorg/w3c/dom/Document;
at org.apache.xalan.xslt.XSLTEngineImpl.process(XSLTEngineImpl.java:356)

Maybe you can't override the xerces and xalan stuff via the ear file, but
instead have to do it on a more system-wide basis (?) Here's another
oddity: when I do put the XML jars in the classes dir so that our code will
work, starting the console causes the following error in the SystemErr.log
though I don't notice any detrimental effects.

java.lang.ClassCastException: org.apache.xerces.dom.DeferredTextImpl
at com.ibm.ws.util.prefs.XmlHelper.ImportSubtree(XmlHelper.java:170)
at com.ibm.ws.util.prefs.XmlHelper.importPreferences(XmlHelper.java:118)
at
com.ibm.ws.util.prefs.BasePreferencesImpl.importPreferences(BasePreferencesI
mpl.java:449)
at
com.ibm.ws.console.core.bean.UserPreferenceBean.init(UserPreferenceBean.java
:58)
at
com.ibm.ws.console.core.bean.UserPreferenceBean.setUserName(UserPreferenceBe
an.java:35)
at com.ibm.ws.console.core.User.valueBound(User.java:64)

Whereas if I put the XML jars in lib/app (instead of the classes dir) our
application works, but the WAS console fails to start with this exception
appearing in the server.

java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at
com.ibm.ws.sm.workspace.metadata.impl.MetaDataParser.parse(MetaDataParser.ja
va:58)

"Sandy Mustard" <sandy....@sdrc.com> wrote in message
news:3E66D89B...@sdrc.com...