tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: JSPC refactoring/documentation
Date Tue, 12 Nov 2002 14:04:43 GMT
Remy Maucherat wrote:
> 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

If I understand correctly, what you are saying above is that Tomcat 4 development
should be frozen except for bug fixes and all changes and new features go in
Tomcat 5?  Is that a correct summary?  If so I think it is premature to do so,
especially since a production quality version of Tomcat 5 could take 6 months.

If we are just maintaining Tomcat 4.1 (bug fixes), I would be willing to port
any bug fixes to the Tocmat 4.1 branch into a Tocmat 4.2 development branch.
And when a 4.2 branch is ready, willing to act as the release manager if you are
not interested in doing so.



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message