xerces and xalan in WEB-INF/lib is not good and needs to be changed....

Hi Christian,

I saw your latest update to put all jars required for runtime in 
WEB-INF/lib.  Although this seems like a logical good idea, it actually 
isn't.  There is a problem with putting jars in WEB-INF/lib which override 
JDK endorsed packages.  It violates the Sun classloading spec and the 
servlet spec.  I think I've posted stuff to the e.org Barracuda list about 
this before?  Basically, it means that Xerces and Xalan can't be in the 
webapp classloader.  It causes all sorts of classloading issues and made 
things seriously break back in the Tomcat-4.0.x days.  Tomcat tries to 
ignore these packages in 4.1.x, but isn't always successful at doing 
so.  Therefore, the current recommendation from Remy (the main contributor 
to Tomcat) and others is to put Xerces and Xalan in parent classloaders; 
CATALNIA_HOME/common/lib, CATALNIA_HOME/common/endorsed (if you want to 
override the JDK's versions), or CATALINA_HOME/shared/lib.  Currently, by 
some luck and some super coding from Richard Kunze, we are able to put our 
version of Xerces in shared/lib even while Xerces2 is in 
common/endorsed.  So, putting all of this in shared/lib is the way to 
go.  It is the least intrusive, follows the servlet and Sun classloading 
specs, and will work with a Stock full version of Tomcat under any JDK.

Here are some of the reasons why I *strenuously* object to putting xerces 
and xalan in WEB-INF/lib...

See:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6248
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6476
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6374

<quote name="Remy Maucherat">
Yes, I know it doesn't happen with b2. There were other more insidious problems
with using a XML parser in a webapp repository (see 6248, and many messages on
tomcat-user).
It will force the XML base classes (and their subpackages, unfortunately, 
that's
where the bug is) to be loaded from one of the parent shared classloader.

I've put a fix already in CVS in both branches (the base XML classes won't be
loaded to avoid the classcasts, but all the subpackages will). It is not
possible, and is actually forbidden by the servlet spec, to load those classes
from the webapp repositories.

LATER means that I'd like to implement a better mechanism to fully 
implement the
spec requirements (although it will need some special configuration by the user
to define which libraries it has installed). This probably will stay in the 
HEAD
branch, so the resolution of the bug may not be the right one.
</quote>

I additon, this has some good explanation:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7175

<quote name="Patrick Luby">
I agree with Remy that you should stop trying to override the default XML 
parser.
While you *may* be able to override it when using JDK 1.3, you will absolutely
not be able to do it with JDK 1.4 as JDK 1.4 treats the XML parsing classes 
(also
known as "endorsed" classes) as system classes. Hence, once the JVM is 
started,
JDK 1.4 will not all any class loader in the process load alternate XML 
parsing
classes that fall in any package names listed in the following URL:

   http://java.sun.com/j2se/1.4/docs/guide/standards/index.html

The only way around this JDK 1.4 restriction for your webapp only is to 
create an
XML parser with package names that are not listed in the above URL (i.e. a 
very
non-standard parser).

There is another way around this restriction. However, it will force all 
webapps
(and the container itself) to use your XML parser. You can put your parser jar
files in the common/lib directory (4.0.x) or in the common/endorsed directory
(HEAD).
</quote>


Also see the bug report I submitted about the error in Tomcat's own 
documentation...
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15115



Of course, now there is the problem with the Barracuda build not cleaning 
up after itself, even after an "ant superclean".  Assuming we want to 
remove Xerces and Xalan from WEB-INF/lib, at the least (and I would also 
vote to remove all the XMLC jars from there as well), we cannot do this 
without manual removal.  A build should always be able to set itself back 
to the exact same state is was before running the build.  Right now that is 
not the case.  Any comments?

Jake