> > Your planning is to release TC 4.0 for late December or early January
> ?-)
> > What about Tomcat 3.2 release ? early December ?
> >
>
> There have been several bug fixes posted for 3.2b8 that I want to
> evaluate, but
> no new critical bugs. Therefore, my inclination will be to cut a final
> 3.2
> release next week, and start doing a maintenance cycle (3.2.1, 3.2.2,
> etc.) as
> needed -- we should discuss this more next week, after all the US folks
> get over
> their turkey hangovers ;-).
Many of the ajp13 bugs seems to be fixed (even the dreaded ajp13 +
RequestDispatcher).
I'm +1000 for the release and maintenance cycle.
My question is about the 3.3-dev ? What will it became. I've got a huge
respect for Costin/Nacho works on 3.3-dev. What will it became ?
Will 3.2.1 will be based on 3.3-dev (yes not revolutin but realistic
optimization) or just bug fixes of current 3.2b8.
> On 4.0 stability? I don't think so. You should consider me to be
> biased
> (Catalina has been *my* baby, after all :-), but I've seen the insides
> of 3.2
> and 4.0 in a lot more detail than I ever hoped to over the last month.
> I have
> come to the following conclusions:
>
> * The servlet container code in 3.2 is *substantially* better
> than the servlet container code in 3.1 in terms of spec conformance,
> number of bugs, functionality, and performance.
>
> * The servlet container code in 4.0 is "more better" than 3.2
> on spec compliance, at least as good on bug counts, and
> at least as good on performance (soon to be better, because
> Remy is working on optimizations on the HTTP/1.1 stack).
>
> * The servlet container in 4.0 sports many additional features
> over 3.2, and only lacks one at the moment -- the ability to
> run a web app under a security manager. That feature can be
> added in 4.1, as soon as someone who understands this stuff
> (Glenn, hint hint :-) can help make it happen.
>
> * The JSP code in 3.2 and 4.0 is pretty equivalent, because we've
> been tracking the bug fixes pretty well in parallel.
>From my end user (production) point of vue, I need the fastest servlet-engine
with a robust WEB Server (Apache) connector. Like many I select ApacheJServ and
next TC 3.x because there was mod_jserv (load-balancing and fault-tolerance).
I'll really start to test TC 4.x when such a connector will be available. I'll
check speed, stability and memory use. Did we must espect TC 4.x to be much
more hungry of bytes that 3.x ?
> There are (at least) two reasons where you would HAVE to choose one
> version or
> the other:
>
> * Do you need web connectors? Go with 3.2 -- this area is
> obviously not mature yet in 4.0.
I'll help on Apache 1.3 connector for TC 4.0 (If I could find more
documentation)
> * Do you need servlet 2.3 or JSP 1.2 features. Go with 4.0
> -- obviously, that is the only place these are implemented.
It's not a priority now for production environment but will became before end
of 2001.
> For any other scenario, you owe it to yourself to evaluate both
> platforms.
>
> Just as a point of interest, Tomcat 4.0 milestone 4 has been downloaded
> just
> under 9,100 times since it was posted on November 1. There have
> certainly been
> some bug reports, but not a large volume -- given the download counts,
> this
> seems to be due more to code quality than people ignoring it :-).
>
> Just as another point of interest, every time I posted a fix to the 3.2
> tree
> over the last couple of weeks, I also looked at whether 4.0 suffered
> from the
> same, or a similar, problem. On the JSP side the bugs were pretty
> consistent in
> both (natural enough, they were the same code base). On the servlet
> side, it's
> happened twice out of about 35 bug fixes -- in both cases where I had
> copied
> utility code directly from the 3.2 code base, and therefore carried
> forward
> bugs.
>
> > >At the same time, we can start talking about features and
> > >functionality we'd like to see in Tomcat 4.1.
> >
> > Whaoo, Tomcat 4.1. Allready ?
>
> Yes. From my perspective, we should consider 4.0 to be in feature
> freeze with
> the addition of the web connectors, so future functionality additions
> should be
> planned for a later release.
>
> >
> > But what about support for Tomcat 3.2.1, 3.2.2, 3.2.3.... (bug fixes)
> >
> > It seems clear for you that Tomcat 3.2 (and the full 3.x line)
> > are allready products in end of life.
> >
>
> I don't think that is actually the case.
>
> Large numbers of people have been eagerly awaiting a 3.2 final release.
> Many
> tool and other vendors have integrated Tomcat 3.2 betas into their
> products, and
> it is not appropriate to encourage them to drop it.
>
> I will be happy to continue applying contributed patches to the 3.2 code
> base,
> and releasing 3.2.1, 3.2.2 type releases as necessary -- pretty much
> along the
> same line that Apache JServ has continued to create bug fix releases as
> needed.
> I'm not planning on doing any new development on the 3.2 track, however
> -- the
> future path is obviously 4.0.
>
If you (and co-workers at Sun) stop working of 3.2 branch, we could imagine the
3.2 will slowly became a dead-end project (like JServ). It don't think it will
be good for Apache & Tomcat to see a split between the 2 Tomcat
implementations. There is many challengers around (Resin, Orion) and I think
all the development forces in Apache Group must go on the same way.
> Aside from the fact that "beta" doesn't really mean the same thing in
> open
> source as it does in commercial products, your point is well taken.
> That's the
> primary reason I went back and picked up the pieces of 3.2 that everyone
> else
> abandoned. The wait for 3.2 is almost over.
Ok, I'll try to fix the remaining ajp13 bugs (many cookies), since like many
others I need ajp13 instead ajp12 to be able to use ssl (Apache/SSL or mod_ssl)
informations in my servlets.
Regards
