A few short comments intermixed below.
[EMAIL PROTECTED] wrote:
> [snip]
> Many of the ajp13 bugs seems to be fixed (even the dreaded ajp13 +
> RequestDispatcher).
>
That's great! Even if you don't get them fixed in time for 3.2 final, rolling out
a maintenance release with those fixes would be very useful.
> [snip]
> >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).
>
The initial code got checked in over the weekend. I need to make sure that it
builds and basically works before cutting a 4.0-m5 release.
>
> 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 ?
>
Hungry in what senses?
* Code size -- somewhat larger, primarily because of new spec features,
but it's a one-time cost so isn't usually significant.
* Per-request object creation -- 4.0 is better than 3.2, not quite as
good (yet) as the current 3.3-dev code but it's getting there.
* Performance -- With the first round of optimizations that Remy
committed on the HTTP/1.1 stack, 4.0 is faster than 3.2 and in
the same range as current 3.3-dev code (which, of course, is a
moving target).
> [snip]
> I'll help on Apache 1.3 connector for TC 4.0 (If I could find more
> documentation)
>
I know Pier has been working on some docs for the protocol, as well as liberally
documenting the code. He's the one to ask any detailed questions. It's in the
"connectors" subdirectory of the "jakarta-tomcat-4.0" repository.
Besides supporting the kinds of existing features that MOD_JSERV and MOD_JK
support, a key design goal has been to make the web connector aware of the contents
of the web.xml file, so we can all stop futzing around with configuring both Apache
and Tomcat to recognize things like servlet mappings, new mime types, welcome
files, and user authentication stuff. That will definitely be a relief to
administrators who install Apache+Tomcat based applications.
>
> > * 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.
>
Just as a note, from the last I saw on TOMCAT-DEV, implementing servlet 2.3 / JSP
1.2 functionality in the "3.3-dev" tree was getting -1'd. It might well happen in
a "revolution" branch, however.
> [snip]
> 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.
>
I don't see any reason for 3.2 to die anytime in the near future. There are *lots*
of people who have adopted it. Maintenance releases (3.2.1, 3.2.2, etc.) that fix
bugs in the current code make a lot of sense -- even Apache JServ had a bug fix
release as recently as June 2000. And I would not be at all surprised if there
were more production apps still running on Apache Jserv than on any version of
Tomcat (I even have a few of my own :-).
Personally, I plan to actively support 3.2.x with bug fixes for as long as it is
appropriate to do so However, I'm not going to do any contribution on the
"3.3-dev" tree. (I will let the other folks that Sun pays to work on Tomcat speak
for themselves, but where the CVS commits are going should give you a pretty good
clue of their intentions :-).
One factor influencing the future directions for web apps that rely on Tomcat 3.x
probably hasn't been highlighted enough. The servlet 2.3 / JSP 1.2 specs *require*
that a 2.3/1.2 container (like Tomcat 4.0) must support servlet 2.2 / JSP 1.1 based
applications (like those supported by Tomcat 3.2). Indeed, this is the case,
unless your app relies on bugs in Tomcat 3.x or it relies on behavior that was
undefined in Servlet 2.2 but has been clarified in Servlet 2.3 (even here, efforts
to improve backwards compatibility exist). The bottom line -- you can migrate
existing apps at your leisure, as soon as Tomcat 4.0 has the features, performance,
and reliability that meets your needs, without needing to rewrite anything.
Having two parallel code bases is certainly not unusual. Consider the Apache web
server, for example -- when 2.0 eventually goes to initial release, are you going
to instantly convert all your 1.3-based apps, or are you going to continue to use
1.3 and migrate at a reasonable pace? I agree with you in the other respect,
though ... having three parallel code bases is pretty silly.
> [snip]
> 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.
>
That would be very helpful.
>
> Regards
Craig
