Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 46222 invoked from network); 16 Aug 2004 15:34:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Aug 2004 15:34:55 -0000 Received: (qmail 13661 invoked by uid 500); 16 Aug 2004 15:34:41 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 13488 invoked by uid 500); 16 Aug 2004 15:34:39 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 13474 invoked by uid 99); 16 Aug 2004 15:34:39 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36) by apache.org (qpsmtpd/0.27.1) with ESMTP; Mon, 16 Aug 2004 08:34:37 -0700 Received: from phys-d3-ha21sca-1 ([129.145.155.163]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i7GFYH6V026713 for ; Mon, 16 Aug 2004 09:34:36 -0600 (MDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I2J00801PMNEU@ha21sca-mail1.sfbay.sun.com> (original mail from jfarcand@apache.org) for tomcat-dev@jakarta.apache.org; Mon, 16 Aug 2004 08:31:57 -0700 (PDT) Received: from apache.org (vpn-129-150-16-42.SFBay.Sun.COM [129.150.16.42]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0I2J005G1PT8F8@ha21sca-mail1.sfbay.sun.com> for tomcat-dev@jakarta.apache.org; Mon, 16 Aug 2004 08:31:56 -0700 (PDT) Date: Mon, 16 Aug 2004 11:36:26 -0400 From: Jeanfrancois Arcand Subject: Re: Tomcat 5.0.28 release In-reply-to: To: Tomcat Developers List Message-id: <4120D47A.1060408@apache.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 References: <9C5166762F311146951505C6790A9CF80229BE54@US-VS1.corp.mpi.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N [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 nightmare....) > > 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: 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