tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Date Sun, 05 Nov 2000 01:13:19 GMT
----- Original Message -----
From: <cmanolache@yahoo.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Saturday, November 04, 2000 4:27 PM
Subject: Re: Tomcat 3.3 / 4.0 confusion, rant and plan...


> And why not:
>
> Servlet2.0 -> Tocmat3.3
> Servlet2.1 -> Tomcat3.3
> Servlet2.2 -> Tomcat3.3
> Servlet2.3 -> Tomcat3.3
> Servlet.next -> Tomcat3.3

I don't agree.
Having :
Servlet2.0 -> TocmatNext
Servlet2.1 -> TomcatNext
Servlet2.2 -> TomcatNext
Servlet2.3 -> TomcatNext
Servlet.next -> TomcatNext
is very fine.

I don't think people want anything but bug fixes (and perhaps a few more
features) for Tomcat 3.2 and eventually 3.3.

> And even:
> "I have old servlet2.2 apps, and some new servlet3.0 apps, and there are
> some incompatibilities between 3.0 servlet API and 2.2, what can I do
> ? " -> Tomcat3.3
>
> Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if
> that it's your concern.
>
> But I don't think you can stop me ( or someone else ) from implementing a
> 3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat.
>
> If the rules for "revolution" are still accepted, I'll do that in a
> /proposal tree, if not - I'll do it on my home page. I think it's the
> right thing to do, instead of rewriting everything again and again.

I think that would be the best. Now, a few points :
- The main branch in the jakarta-tomcat tree is broken, and is also a bug
mess right now. I think it needs to be fixed so that it complies more with
the objectives set for TC3.3.
- If it was possible to avoid code duplication for as many components as
possible it would be great ;) Fixes / improvements are really hard to merge
otherwise. Since I think the main point of disagreement is the servlet
engine core, that should be doable.

> That's the main issue here, and that's what I think it's wrong in your
> table - the code should be reusable, and supporting multiple facades is
> not only easy, but it's important for future.

Remy


Mime
View raw message