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

Ok, so I've updated the build.xml to NOT put xerces and xalan jars in the
WEB-INF/lib dir when the 'install' target is run.

Per your comments on cleaning up the jars in /lib, I've added that to the
clean target. Note however that if Tomcat is running Ant may not be able to
delete these jars because Tomcat locks jars in the /lib dir...
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

  -----Original Message-----
  From: [email protected]
[mailto:[email protected]]On Behalf Of Jacob Kjome
  Sent: Thursday, January 16, 2003 10:02 PM
  To: [email protected]
  Subject: [Barracuda] 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