> 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.*.
This is an ugly hack though :-) If another app using the same server and
relies on Xalan-1 functionality, they're screwed.
> with Resin and I never tried with Tomcat.
Tomcat 4 fixes this (mostly)
> 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,
Yes, sort of. The problem is that the same classloader used by your web-app
can also 'see' the global 'classpath ' set by Orion, and, as classloaders
delegate, when the web-app CL tries to use an XML parser, or Xalan or
something that is shared then the 'global' one gets used first.
> 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,
That was me
> 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.
> "
Yes, we put this in because of these sorts of problems.
Kevin Jones
DevelopMentor
www.develop.com
