Re: WebSphere & Xerces/Xalan -- JAVA400-L

Not sure if this will help you, but maybe worth a shot.  Change your
admin.properties file back to what it was originally, that way at least the
admin server will be using the version of xerces which it was expecting.  I
saw this posted by someone on the iSeries websphere newsgroup, pasted
below:

"try forcing xerces.jar to the front of your classpath by adding -classpath
/QIBM/ProdData/WebASAdv/lib/xerces.jar as a command line argument for your
Application Server (Click on the Application Server and select the
'General'
tab.  There will be a field 'Command line arguments').

You'll need to stop and start the app server for the change to get picked
up."

No guarantee!


tmalin@csc.com@midrange.com on 09/12/2001 10:42:36 AM

Please respond to java400-l@midrange.com

Sent by:  java400-l-admin@midrange.com


To:   JAVA400-L@midrange.com
cc:
Subject:  WebSphere &  Xerces/Xalan



Anyone know a fix around this problem, we are using a newer version of
Xerces/Xalan than WebSphere's version. We are using WebSphere 3.5.4
Advanced edition. We also tried changing the admin.config file classpath to
recognize our version, but it did not work.

We get the following exception: (Lorg/apache/xerces/dom/DocumentImpl;)V not
found


I read this post from ejbinfo.com
*** WebSphere has started to use xerces from apache starting it seems with
PTF 2. This article covers what you need to know if you also use xerces or
xalan in your server application ***

If you're using Xerces/Xalan and WebSphere then your life has become a
little more complex (or simpler, depending on your point of view)with PTF
2. The WebSphere runtime now uses Xerces for some of its work. This means
that you cannot use any version of xerces (and by consequence xalan) you
want in your servlets or EJBs. WAS 3.5 PTF 2 ships with V1.1.2 of xerces.
You can discover the version by unjaring the provided xerces.jar and
xalan.jar jars. There is a file at the root of these jars giving the
version. You should use the jars from the appserver/lib directory when
developing xml/xsl applications now and in the future. When you get a new
version of WAS or a new PTF then you should update your development
environment with the new jars shipped with the product.


If you don't do this then you run the risk of breaking the WAS runtime by
forcing it to use a different version of xerces/xalan than it was built
with. The xerces.jar is specified automatically (it's in admin.config) on
the classpath. You still need to specify xalan.jar on the command line
class path if you use xsl as well.


This type of problem is likely to become worse as WebSphere starts to use
other Java technologies. You'll have to find out what version it uses and
then you are limited to using the same jars as it is using in your code.
But, other app server vendors will have the same problems if they do
likewise.


Thanks,


Tom

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.