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 ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
