tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: Missing DataSourceRealm MBean definition
Date Fri, 07 Nov 2003 14:08:25 GMT
At 07:22 AM 11/7/2003 +0100, you wrote:
>Christopher Schultz wrote:
>>>Tomcat5 no longer provides a separate "LE" version.  You can take that 
>>>as a hint not to use the "LE" version in Tomcat4.1.x.  It causes nothing 
>>>but confusion.
>>I disagree. The 'LE' version actually has less confusion because there 
>>aren't fighting XML parsers involved.
>>I don't know why Tomcat 5.x doesn't have an 'LE' version. I couldn't find 
>>any official word that LE versions "caused confusion and have been 
>>elimintated" :)
>I would second your point of view IF guys who make LE version gave us 
>pointers to ALL missing components, like JavaMail, etc.

Yep, and my argument is based on what *is*, not what should be.  There *is* 
confusion, I wish there weren't.

>On the other hand, using system-wide XML parsers, and only those, has a 
>drawback. Suppose one of your applications needs a particular version, 
>while it doesn't sit well with Tomcat. What confusion will ensue then?

Well, what is your alternative?  It violates the sun classloading and 
servlet specs to load an XML parser from the WebappClassLoader and Tomcat 
enforces this.  The same applies to any packages that already exist in the 
JDK.  Furthermore, he "LE" version is meant to be used with j2sdk1.4+ which 
will force its own XML parsers (Crimson, Xalan, and the non-standard - at 
least w3c dom - XML parser API's that they include with it) on you unless 
you override it using the endorsed standards override mechanism.  This is 
where Tomcat's common/endorsed directory comes into play.

Given that info, what are you trying to say?  The fact is, you can't 
include your own XML parser per webapp in the same running container.  This 
may very well cause confusion, but you'll have to talk to Sun about its 
classloading rules, not the developers of Tomcat.

>I believe that Craig commented something like that on the notion of having 
>"global" Struts installation in Tomcat. OK, granted, it makes more sense, 
>since you can build your WebApp for a particular version of Struts, while 
>XML API should stay the same. But still, if you have a combo that is 
>working - Tomcat X.Y.Z and Xerces A.B.C - then it is reasonable to ship it 

I disagree with using a global version of Struts and I'm surprised Craig 
even said that since he has, as far as I am aware, always been a proponent 
of *avoiding* using libraries in a global classloader.  This is not only 
problematic for the reasons you state, but what do you do about static 
variables?  If they are set for one app, they are set for all.  Not 
good.  And, as I said before, you can't include your own XML parser in 

Your alternative to all this is to have separate Tomcat containers running 
apps that require different XML parsers with your preferred XML parser APIs 
in each respective Tomcat's common/endorsed directory.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message