org.jdom.JDOMException: Error in building: SAX2 driver class org.apache.xerces.parsers.SAXParser not found: org.apache.xerces.parsers.SAXParser
We dont know if this is parser is inbuilt in webMethods or if this is a third party tool that would have got installed in the server.
Our webMethods Administrator who supported the application initially had to leave abruptly , and we are testing the application after migrating it to a different system – without much documentation.
Thanks!!
KS
I will assume you are running IS 6.x on Windows:
In server.bat change
SET USE_ENV_CLASSPATH=true
to
SET USE_ENV_CLASSPATH=false
this will avoid putting anything that is on your system’s classpath on the IS classpath, which will avoid errors caused by other stuff on your box. I don’t know of any webMethods software is dependent on anything being on the CLASSPATH variable.
If this does not work, please give more information about what system you are runnong on, and what is going on when you get the exception.
Hi Fred, Thanks for the response.
We are testing this application on UNIX running wM 6.0.1(we just migrated it from WindowsNT).
On a second run, I find that it fails at a particular java service which imports some classes from a jar file… which apparently resides in that packages’ code/jars directory. So I am not sure why it is not able to find it.
Any Help appreciated.
KS
May guess is a jar collision.
Did it work since migrating from NT or is this the first time the IS has been started up on Unix?
What package is throwing the exception?
Look at the server About page and see if there is something on the classpath that should not be (like a xercesimpl.jar or jdom.jar from another application).
Hi Fred,
The service used to work on the NT platform, this is the firt time, we are testing it after migrating it to UNIX. We were stepping through the services until we got this error at the java service,
I am confused about the classpath because while the application was in NT, it didnt have any classpath set, so not sure why it would need one after migration.
The service that throws the exception is the one that converts a proprietary format to XML format and is a java service…
KS
The classpath is used by the JVM and was built as part of the server.bat file on windows. In a UNIX environment, the classpath is also built by the server.sh script. It’s always present.
Look at the NT java services shared tab. Does this match the new shared tab? It looks like it’s missing an imported jar file.
HTH,
Jim Palmer