Done: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15115
Jake At 09:52 AM 12/5/2002 -0500, you wrote:
open an enhancement in bugzilla for this update to ensure that is doesn't
get lost. I'm sure its just a carryover from the 4.0 release.
Charlie
> -----Original Message-----
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 04, 2002 11:52 AM
> To: Tomcat Users List
> Subject: Re[2]: WebApp Classpath
>
>
> Hello Yoav,
>
> I see a problem with the documentation. It says:
>
> <quote>
> xerces.jar - The XML parser that is visible by default to Tomcat
> internal classes and to web applications. This can be overridden, for
> a particular web application, by including your desired
> parser in /WEB-INF/lib.
> </quote>
>
> That is very wrong and violates the Sun classloading spec. Tomcat has
> enforced this since 4.0.2, but things were buggy at that time so
> Tomcat didn't do a perfect job at ignoring the XML parser. Instead,
> you'd get ClassCastExceptions and such. I'm
> pretty sure Xerces is mostly ignored in Tomcat-4.1.12. The XML parser
> should exist in one of a few places:
>
> 1. In the JDK (true with j2sdk1.4.x)
> 2. Overridden in JAVA_HOME/jre/lib/endorsed
> 3. Overridden in CATALINA_HOME/common/endorsed
> 4. Be placed in CATALINA_HOME/common/lib. Note that this will not
> override existing XML parsers from endorsed directories, but if you
> are using JDK1.3.x, then it will be used since that JDK version
> doesn't include an XML parser. The Xerces classes will be
> loaded either way...unless the full Xerces is in an endorsed directory
> already.
>
> See also:
>
> 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>
>
>
> The docs should be changed to match the latest reality. The XML
> parser *cannot* be overridden by putting it in WEB-INF/lib.
>
>
> Jake
>
> Wednesday, December 04, 2002, 8:52:46 AM, you wrote:
>
> SY> Hi,
> SY> Really? You didn't find anything in the docs to even
> shed a little
> SY> light? Try:
> SY>
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html
SY> (You didn't mention what tomcat version you're using, so I'm assuming
SY> 4.1.x).
SY> Also see the section in the release notes titled "Tomcat and XML
SY> Parsers."
SY> Yoav Shapira
SY> Millennium ChemInformatics
>>-----Original Message-----
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, December 04, 2002 9:23 AM
>>To: [EMAIL PROTECTED]
>>Subject: WebApp Classpath
>>
>>Hello,
>>
>>I face a problem using Tomcat with our Web Application regarding Xalan.
>>We are using a quite old version of Xalan in our application (it is
>>somewhat
>>1.x). Now our application refuses to run on Tomcat since Tomcat puts in
SY> the
>>classpath a Xalan version 2.x.
>>Is there a possibility to provide a separate classpath for Tomcat and
SY> the
>>Web Application? (other Application Servers provide this feature, but I
SY> did
>>not find anything about it in Tomcat)
>>
>>Thanks for your help,
>>Harald Dietrich
>>
>>--
>>To unsubscribe, e-mail: <mailto:tomcat-user->>[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:tomcat-user->>[EMAIL PROTECTED]>
SY> --
SY> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
SY> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
Best regards,
Jacob mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
