tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5
Date Wed, 04 Dec 2002 18:15:43 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 
 > 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.
 >> I'd like to point out that Jasper 2 from TC 5 is diverging from 
Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase 
and some facades for that too ? ;-)
 > No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
 > sense to do so, also jasper is primarily implementing the JSP spec.
 > Whereas the core of catalina is where all the non spec related 
features get added.

I mentioned Jasper since it was in your list of components in common.

 >> Connectors is in common, because of the set of facades used in Coyote.
 >> I have no interest in that project, and see no point in trying to 
extend the life of the old API (given that the new one is quite similar).
 >> -0 from me (ie, go ahead if there's some developer interest; of 
course, implementation details will need to be discussed further).
 >> Remy
 > 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 am not against it (I would have been -1). I just think it is not such 
a great idea, so as it stands, I do not support it and don't plan to help.

BTW, I have been regularly adding features to 4.1.x, excluding the 
features which change existing behavior or lead to API changes (of 
course, given your recent posts, I guess you don't really know what 
occurred in tomcat-dev in the last 2 months). Please read the commits 
and the changelog.

 > 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 

Glenn, I do not understand what is it that is not in 4.1 that you would 
want to add. Costin posted a comment the last time you mentioned 4.2 (I 
think it was one month ago), and I fully agree with it.

If you want to make a proposal, including a revolution, please do so. As 
is, my personal opinion is that having a common j-t-catalina between 4.x 
and 5.x is not doable from a technical standpoint (given that we have 
limited development resources), and even not desirable, as some API 
changes will be needed to make Catalina faster (right now, mapping and 
auth are really slow, and will need access to j-t-c/util objects to have 
acceptable speed and GC behavior).

Another possibility, given that the API 2.4 is close from 2.3, is that 
we release j-t-catalina as part of a 4.2 release, and advertise it as 
supporting servlets 2.3.


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

View raw message