tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cox, Charlie" <c...@cincom.com>
Subject RE: Re[2]: WebApp Classpath
Date Thu, 05 Dec 2002 14:52:55 GMT
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:hoju@visi.com]
> 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: h.dietrich@webfair.com [mailto:h.dietrich@webfair.com]
>>Sent: Wednesday, December 04, 2002 9:23 AM
>>To: tomcat-user@jakarta.apache.org
>>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-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user-
>>help@jakarta.apache.org>


SY> --
SY> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
SY> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>



-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message