Question on changing the order that the classloader uses in 3.2

[Brett Bergquist <bb...@snet.net>]

I have a problem with using 3.2.  My servlets use the old "xml.jar" XML
parser.  They cannot be changed at this point in a timely fashion.  I
downloaded and installed the 3.2b7 release and tried my web application.
Unfortunately, there is some incompatibility between the Sun parser that is
in the "xml.jar" and the one in the "parser.jar" even though the classes and
interface in "parser.jar" seem to be backward compatible because my classes
load okay.  The incompatibility is that the parser appears to be doing
something that causes extra Text noded consisting of whitespace to appear in
the DOM tree even after calling Element.normalize().  I've narrowed it down
to the parser classes by doing the following:

	1. I created a directory "classes" in the tomcat home directory
	2. I copied the com.sun.xml.parser.* to this directory
	3. Started tomcat using the startup.bat file.

Now since the startup.bat file puts the "classes" directory first in the
classpath for Tomcat, it is now picking up the old parser classes.   My
application now works as it used to.

I don't know if I will be able to fix this problem or change to the new JAXP
interface in a timely manner.  Because of this I would like to have my local
copy of "xml.jar" used by my servlets.  I've perused the mail archives and
also the source for 3.2 and between the two have determined that the class
loader order is:

	1. Parent class loader
	2. System class loader
	3. Servlet class loader (which looks in WEB-INF/classes and WEB-INF/lib

I also noticed that this is not the order for Tomcat 4.0 which moved (3)
before (1).  I'm wondering if I could do the same for Tomcat 3.2 (my local
copy only and not as a patch).  I don't see why this would hurt other than a
possible security problem with local classes being able to override system
classes, but in my case this point is mute since I install Tomcat, all of
the Web apps, and no other applications are ever loaded or could be on the
system.  Am I missing something?

Thanks for any insite

Brett M. Bergquist

Re: Question on changing the order that the classloader uses in 3.2

[Jim Rudnicki <jd...@pacbell.net>]

This was discussed on this list a while back.  The problem was security
would be difficult/impossible to maintain if the order was changed.  There
was a small debate about the security issue.  Nonetheless, in 3.x, the
engine will bleed its xml parser and dependencies upon all servlets.  If you
cannot coexist with the classes, you're toast.  Makes one regret ever
hearing 'bout XML, huh?

Recently I had some hope.  The Oct 31 JDC Tech Tips discusses using
"classloaders as a namespace mechanism".  At first read it discusses
problems just like this and it may offer the solution.  But I'm not sure if
servlets will be able to build classloaders that change the order desired by
the system.  Give it a look.

Jim

----- Original Message -----
Subject: Question on changing the order that the classloader uses in 3.2


> I have a problem with using 3.2.  My servlets use the old "xml.jar" XML
> parser.  They cannot be changed at this point in a timely fashion.  I
> downloaded and installed the 3.2b7 release and tried my web application.
> Unfortunately, there is some incompatibility between the Sun parser that
is
> in the "xml.jar" and the one in the "parser.jar" even though the classes
and
> interface in "parser.jar" seem to be backward compatible because my
classes
> load okay.  The incompatibility is that the parser appears to be doing
> something that causes extra Text noded consisting of whitespace to appear
in
> the DOM tree even after calling Element.normalize().  I've narrowed it
down
> to the parser classes by doing the following:
>
> 1. I created a directory "classes" in the tomcat home directory
> 2. I copied the com.sun.xml.parser.* to this directory
> 3. Started tomcat using the startup.bat file.
>
> Now since the startup.bat file puts the "classes" directory first in the
> classpath for Tomcat, it is now picking up the old parser classes.   My
> application now works as it used to.
>
> I don't know if I will be able to fix this problem or change to the new
JAXP
> interface in a timely manner.  Because of this I would like to have my
local
> copy of "xml.jar" used by my servlets.  I've perused the mail archives and
> also the source for 3.2 and between the two have determined that the class
> loader order is:
>
> 1. Parent class loader
> 2. System class loader
> 3. Servlet class loader (which looks in WEB-INF/classes and WEB-INF/lib
>
> I also noticed that this is not the order for Tomcat 4.0 which moved (3)
> before (1).  I'm wondering if I could do the same for Tomcat 3.2 (my local
> copy only and not as a patch).  I don't see why this would hurt other than
a
> possible security problem with local classes being able to override system
> classes, but in my case this point is mute since I install Tomcat, all of
> the Web apps, and no other applications are ever loaded or could be on the
> system.  Am I missing something?
>
> Thanks for any insite
>
> Brett M. Bergquist
>
>
>