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 15:58:16 GMT
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.
> 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 ? ;-)
> 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).

I'd like to add that these comments only apply to a portion of the code 
in j-t-catalina. A significant amount of code is independent (the 
stores, the auth, the realms, etc, etc), and could be put in that 
legendary j-t-modules repository ;-)

I don't see how j-t-jasper could be independent of the API (nor the rest 
of j-t-catalina); at least not without a prohibitive amount of work.


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

View raw message