Because of the way Tomcat 3.2.x sets up its classloader
hierarchy, you are stuck. I'm not aware of any tricks
to allow your library to remain in /WEB-INF/lib and
xerces and xalan to remain in the "application" classloader.
However, this issue is addressed in Tomcat 3.3 and
Tomcat 4.0.
In Tomcat 3.3, a more complex classloader hierarchy is
built which separates the server classes (which includes
the server's XML parser) from the web application's classes.
Now web applications can have their own XML parser.
In Tomcat 4.0, per the servlet 2.3 spec, classloaders
try to load the class first before delagating to their
parent. Thus, an XML parser in /WEB-INF/lib would
"override" an XMP parser in a parent classloader.
There is probably more to this story for Tomcat 4.0, but
I will let someone with more experience than me
elaborate.
Cheers,
Larry
> -----Original Message-----
> From: Dmitry Beransky [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 09, 2001 7:43 PM
> To: [EMAIL PROTECTED]
> Subject: xalan and problem with locating custom libraries
>
>
> Hi,
>
> I need to use XSLT from inside jsp. I decided to go with
> Xalan/Xerces and
> in order to make them work under Tomcat (3.2.2), I replaced
> jaxp.jar and
> parser.jar with xalan.jar and xerces.jar in tomcat's lib
> directory. Everything works fine, until in my stylesheets I
> try to make
> use of custom Java extension functions. These extension
> functions are
> specific to the application (context) in which they are
> running and are
> defined in a jar file located in /WEB-INF/lib of the same
> context as the
> jsp files that initiate XSLT processing.
>
> The problem is that the xsl engine doesn't see my libraries.
> And it makes
> sense, since the engine sits in xalan.jar which is loaded at
> startup and my
> application libraries are loaded later by a different class
> loader. An
> obvious work-around would be to have these libraries loaded
> at startup
> too. But I REALLY, really hate doing this, because they simply don't
> belong there. This doesn't strike me as neither a secure nor
> a scaleable
> solution. But it's the only solution I can think of.
>
> Is there something else I can do?
>
> Regards
> Dmitry
>
