Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

[Remy Maucherat]

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


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.

Remy


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>