tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <>
Subject Re: Tomcat 5.0.28 release
Date Mon, 16 Aug 2004 15:36:26 GMT
[back from vacation :-)]

Costin Manolache wrote:

> Shapira, Yoav wrote:
>> Hi,
>> I have a couple of only-slightly-related comments, but related
>> nonetheless so I'll put them here.
>> Re: endorsed directories.  Do we still want to support JDK 1.3 in Tomcat
>> 5.1?  Since we're gearing up for JDK 1.5, we might want to make 1.4 the
>> minimum.  I'm +0.5 on this.
> First, endorsed directories are _not_ for 1.3, but for 1.4 ( to 
> override the build-in parser and the check they do on load ).
> 1.3 works fine with just having the parser in classpath, or in 
> /jre/lib/ext, and it's quite simple to add code to the loader to add 
> the parser packages only if 1.3 is detected.

Except if you turn validation on, which will not works since XML schema 
is not supported in Crimson or early version of Xerces (remember the 

> I'm using JDK1.3 most of the time, and I think a lot of other people 
> and companies are still using it. I don't mind having the default 
> distribution built for 1.4+ ( no xerces ), with instructions on how to 
> get the additional jars for 1.3. But I think it would be very bad to 
> not be able to run in 1.3 - and I don't see any good reason to justify 
> forcing the users to upgrade.

One question we should explore is do we really wants to have a 
dependencies on Xerces? Like you already said, a pull parser might be 
better, smaller and more stable than having to rely on Xerces. Not sure 
if pull parser supports schema yet...

+1 of dropping Xerces ;-)

-- Jeanfrancois

>>> them. I prefer the latter approach, also because of the multi-user use
>>> case: if a single Tomcat installation (CATALINA_HOME) is used by
>>> multiple users (each having their own CATALINA_BASE), then the former
>>> approach does not work if each user has a different version of the JDK.
>> How about stopping support for that scenario?  I mean drop the
>> CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal
>> each other, if we want to leave them in the code base), and don't allow
>> users to share installations except by the user home directory valve.
>> The disk space benefits aren't worth it.  The central administration
>> benefits might be, but I wonder how many people use this.  Maybe an
>> informal survey on the user list is worth doing?
> How about the other way around - stop support for the combined tomcat, 
> and default to multi-user ( or multi-config ).
> I would be very happy to see the server layout change to support 
> multiple configurations.
> Something like:
> /bin
> /lib - with manifest/properties file used to select what goes to 
> common, server, shared :-)
> /servers
> /servers/all
> /servers/minimal
> With conf/ and webapps/ under each server.
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message