Hi Kevin,
I'm using Xalan 2 in my framework and I've had the same problem with
pretty much all the containers that I've tried playing with. With Orion,
substituting xalan.jar and xerces.jar in the orion directory did the
trick for me in 1.4.*. I think I remember I had to do something similar
with Resin and I never tried with Tomcat. The problem seems to be
something like "the first XML library to be used is the one to be used
for everything" and as all the containers have nowadays XML
configuration files and use an XML parser as soon as they start up, then
the XML library that is used is the one that the container uses, hence
the need to put your desired library in the global CLASSPATH. This can
lead to problems that can't be solved, if the container and your
application can only use incompatible versions of a parser. As somebody
mentioned, I think JSDK 2.3 tries to solve this, specifically,
Point SRV.9.7.2 Web Application Classloader (Page 63 JSDK2.3 PFD2)
states:
"...
It is recommended, however, that the application classloader be
implemented so that classes and resources packaged within the WAR are
loaded in preference to classes and resources residing in container-wide
library JARs.
"
That should mean that the parser installed in the application classpath
should be used in your applications over the one installed in the global
classpath, but unfortunately it is just a recommendation so who knows
what will happen :).
Just my 2c,
D.
Kevin Jones wrote:
>
> and the point is that I shouldn't need to put the classes/jar in the Orion
> lib. I should be free to put whatever classes/jars I need in my own
> application.
>
> The only thing about this is that it is not an easy problem to solve (ask
> the Jakarta/Tomcat team), and for some reason it always seems to happen with
> XML/XSLT processors :-(
>
> Kevin Jones
> DevelopMentor
> www.develop.com
>
<snip>...
