tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5
Date Wed, 04 Dec 2002 18:47:02 GMT
Glenn Nielsen wrote:

> Remy Maucherat wrote:
>> Glenn Nielsen wrote:
>>> With Tomcat 4.1 released many tomcat developers have been reticent to
>>> add new features
>>> to its codebase for a number of reasons.  All the development going on
>>> in Tomcat 5 and
>>> wanting to keep the number of codebase's where bug fix patches have to
>>> be applied to a
>>> minimum.
>>> There are alot of ideas for new features that I would like to see end
>>> up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 2.0
>>> specs will be finalized
>>> so that Tomcat 5 can be released.
>>> There isn't that much difference in the core of catalina between the
>>> Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the
>>> jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this
>>> codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then have a
>>> common codebase
>>> for applying bug fix patches.
>>> This seems to fit in with the direction we have been going where
>>> different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>> Comments?
>> This is hard to do (Catalina has never been written to allow facades).
>> Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.
> Right, I am aware of that. There isn't that much difference between
> Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make addition of
> new non spec related features easier and bug fix patching easier.

There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

> There needs to be someplace where new features can be added to the Tocmat
> 4 branch. You have been against adding new features to Tomcat 4 head,
> creating a Tocmat 4.2 branch for developement, and now against making
> j-t-catalina common to both Tomcat 4 & 5.

I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.

> If this is what you want then perhaps you should propose a VOTE to freeze
> all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the community
> votes to do that then I will stop asking and perhaps go review the rules
> for revolutionaries.

I don't see the point of a vote to freeze ( and I think it would be a very 
bad idea ). 

Tomcat4 ( and tomcat33 - I think ) can get new features if enough interest
exists. They do get new features all the time ( at connector level ). 
If any of the features in 5.0 gets 3 +1 for porting it back to 4.x - 
then it should be done. 

If we move auth* and other stuff to couyte level and use Action - more 
featurs will be common across versions.

You can start a revolution and make any changes you want in proposal/, but
you'll still need at least 3 +1 votes to release it (well, you need a 
majority - but again I don't see why anyone would vote -1 ).


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

View raw message