Re: WebSphere & Xerces/Xalan

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Tom,

It sounds like you are using 1.4.3, which is where some of the dom DocumentImpl
classes were reorganized.  You might try 1.4.2. I have not tried Xerces and 
Xalan
on the latest version of WebSphere, but if I were IBM I would make it a number 
one
priority to document how you can use 1.4+ in WebSphere. The support provided
by 1.4 is absolutely essential to the types of applications that run on the 
iSeries.

David Morris

>>> tmalin@csc.com 09/12/01 09:42AM >>>
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