Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3DCFB51A.1000900@mail.more.net>
Date: Mon, 11 Nov 2002 07:48:10 -0600
From: Glenn Nielsen <glenn@mail.more.net>
Organization: MOREnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020909
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: JSPC refactoring/documentation
References: <3DCF43C3.9080904@mail.more.net>
 <00a601c28957$a2ae7ee0$d2b32b04@dslverizon.net> <3DCF96DA.5080809@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Remy Maucherat wrote:
> Bill Barker wrote:
> 
>> >Based on problems reported by users of JSPC Remy made a proposal
>> >to deprecate it.
>> >
>> >This resulted in a number of people responding that they used JSPC
>> >and strongly felt it should be kept.
>> >
>> >There did seem to be some consensus that JSPC could beneifit from
>> >a review and refactoring to make it easier to use.
>> >
>> >It could also benefit from better documentation if it is to remain
>> >part of Tomcat.
>> >
>> >Perhaps those who so strongly support JSPC should take the lead to
>> >review, refactor, simplify, and better document JSPC.  Perhaps a
>> >JSPC-HOWTO for the Tomcat docs once the refactoring is completed?
>> >
>> >
>> >This could be part of a Tomcat 4.2 development effort.
>> >There has been some discussion about other possible new features.
>> >
>> >Some new features/changes that have been discussed:
>> >
>> >A SecurityManager XML Policy file that allows secure delegation
>> >to web applications for setting their own policies (within a sandbox).
>> >
>> >Using JMX to instrument Tomcat for production runtime monitoring.
>> >
>> >Possibly a JSPC refactoring.
>> >
>> >Audit the SecurityManager web application sandbox.
>> >
>> >Are there other changes/features that could be part of Tomcat 4.2
>>
>> development?
>>
>>
>> >From previous posts, I gather that Remy isn't interested in RMing a 4.2
>> release.  Unless Remy jumps in and tells me that I don't know what I'm
>> talking about :), the biggest change would be to find someone to 
>> volunteer
>> to RM it.
> 
> 
> 
> I think we have too many dev branches already, and this is causing 
> maintenance problems.  I'd like to have those things go in either 4.1 or 
> 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1 and 
> not really usable to a normal Tomcat user, it needs to be fixed in 
> 4.1.x. Please :)
> 

Doing development in the 4.1 branch would limit the ability to do bug
fix releases on 4.1.  Perhaps if an effort to resolve all know 4.1
bugs was made we would see the number of bug reports for 4.1 decrease.
That would make a 4.2 development branch easier to do while still maintaining 4.1.

We could try to keep the time 4.2 is in development to a minimum,
perhaps a couple of months.  Once 4.2 was released the 4.1 branch
could be retired with all bug fixes going in 4.2 (HEAD).

Why not wait and see if there are more signficant changes/new features
proposed for a possible 4.2 release. And if there are committers willing
to assist porting bug fixes between the branches while 4.2 is under
development.

> I'd also like to point out that the servlet API changes are very 
> limited, and it will be possible to use Tomcat 5.0 with the Jasper from 
> Tomcat 4.1. So I think "major" new features should go in the 5.0 codebase.
> 
> R�my
> 

What is a realistic timeline for 5.0 being released?

Regards,

Glenn


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>