tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Tomcat 5.0.28 release
Date Tue, 17 Aug 2004 03:42:10 GMT
Jeanfrancois Arcand 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 
> nightmare....)

Yes, schema validation on JDK1.4 is lost because the parser doesn't 
support it well enough.

I think it may be better to just check if the parser supports schema 
validation, and if not just display a warning that schema validation is 
disabled on parser that don't support it. It's easy to detect what 
version of xerces or if crimson is used.

Fact is a lot of parsers don't support schema validation, and it is 
better to allow tomcat to work with any parser than try to force a 
specific version of parser.

Well, the right solution is to just remove the option to turn schema 
validation on at startup - it is a huge waste of time at startup, it 
should be done only at deploy time by deploy tools :-)

>> 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 ;-)

I don't think many pull parsers support schema, they are supposed to be 
faster and simpler :-)

It's not about dropping xerces - we will still use the xerces inside 
jdk1.4 and jdk1.5 - we just shouldn't force a specific version and take 
all the pain for endorsed.dir - but let the user use whatever Jaxp 
parser he wants and disable schema validation if the parser doesn't 
support it.


> -- 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