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.
No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
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 ? ;-)
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.
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.Connectors is in common, because of the set of facades used in Coyote.There needs to be someplace where new features can be added to the Tocmat 4 branch.
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
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.
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 onGlenn, 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.
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.
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]>
