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