tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: JSPC refactoring/documentation
Date Mon, 11 Nov 2002 18:10:58 GMT
Glenn Nielsen wrote:

> Remy Maucherat wrote:
>
> > Bill Barker wrote:
> >
> >
> >
> > 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.


So far, I'm not in favor of a 4.2 branch, as I would like to avoid 
fragmentation. If:
- 4.1 is put in a security-fix only mode
- all new features are ported to 5.0
- all relevant bugfixes are ported to 5.0
Then fragmentation cannot happen, and I would be in favor of it, and 
could maybe RM it (since I wouldn't be doing anything on 4.1), if 4.2 is 
proven to be useful.

On the features list:
- A SecurityManager XML Policy file that allows secure delegation
to web applications for setting their own policies (within a sandbox): 
as far as I can remember, this recieved negative feedback. This is sort 
of something which IMHO should be part of a future JDK. I don't really 
see what it has to do with Tomcat (except if would be a useful JDK 
feature to use). It could be developped in the Commons sandbox if you're 
interested.
- jspc: it should be done in 4.1 (it is not really usable at the moment 
unless you know the code). Even if it's a major refactoring, we have to 
do it there *or* we have to remove the feature for now. Given the 
different view everyone has on jspc (and me who doesn't really care 
about what it does ;-) ), I think someone should start a poll on which 
committers would vote.
- Using JMX to instrument Tomcat for production runtime monitoring: I 
have no idea what you want to do. I think it might be better in 5.0.
- Audit the SecurityManager web application sandbox: This has been done 
in 5.0, and the result could be ported to 4.1, esp if the sandbox is 
somewhat deficient.

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


I'm now independent and unemployed, so I'm not aware of the Sun 
schedules for the spec anymore :-P Probably within 3-6 months given J2EE 
1.4 is in beta. The rule is we cannot release a stable version of 5.0.x 
until the specs are final.

Rémy


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


Mime
View raw message