Costin Manolache wrote:
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.
Yes, probably moving some code would be a nice solution. I'd prefer
j-t-modules for that use, personally.
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.
This is a conspiracy ;-) I already voted -0 ;-)
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
