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.
Costin
>
> -- 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: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
|