"Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>
>> As far as I would like to see WARP and its future development, it'll
>> probably end up following a different container architecture. The
>> extenization of the HTTP stack from the core of the container brings some
>> advantages to the engine, but as well this need to introduce a different
>> layering scheme for the components, such as the removal of <Host>.
>
> I'm not sure I quite understand why you say that.
>
> In that deployment scenario, you use:
> - Coyote HTTP/1.1
> - Catalina 2.0
> and this is not fundamentally different that the current Tomcat 4.1. The
> main difference is that the loader will probably be different, but
> you'll still be able to use the old one if you need to.
I am not inclined towards the usage of an HTTP protocol different from
Apache HTTPd, our flagship product. The servlet container should be only
that, a servlet container, without anything else (no HTTP, no CGI, no SSI,
no JSP, no TURBINE, no NOTHING)... Only in this scenario, with a clear
separation of what is what, we can suitably achieve a decent servlet
container, as JServ was back in the days.
> Actually, if you package the current o.a.c.connector classes with the
> webapp classes, you should be able (maybe after adding one or two new
> methods for the new Servlet API, but it shouldn't be too hard) to run
> Webapp 1.0 on TC 5.
As I said, I am not confident in Tomcat as of _NOW_ to run on _MY_
production site. I don't want to think about a new upcoming and improved
release when IMO, there's still so much crap to do with the current code
base.
>> Plus, for security reasons, I want WebApp to follow the trend of being
>> slimmer, therefore not inheriting the whole "Tomcat" weight, but letting it
>> do only _the_ container, with no kits or caboodle attached to it... Apache
>> is my platform, there is where I will want and add complexity. Tomcat, just
>> a servlet container (IMO)...
>
> Rewriting WARP for Coyote wouldn't be that difficult, IMO. It just
> changes the way you communicate with your lower layer, and that's about
> it. I believe Costin wants to improve the "action" stuff used currently
> to be more flexible and powerful.
That would be a waste of time and CPU resources... You're looking in the
wrong direction... To get performance, and reliability, all you have to do
is simplify the code, removing layer after layer... Not adding them...
> In return, you get a GC friendly behavior of the connector, higher
> performance, and it should also be easier to adapt to future version of
> Tomcat and / or may be used by other containers.
FWIW, I don't care about other containers... And I won't care about future
revisions of Tomcat until this one "works for me"...
>> This is where I want to end up to. Frankly at this point in time I don't
>> think that carrying on with the development of components such as the HTTP
>> connector, or other tomcat "features" (GZIP on-the-fly compression, CGI
>> support, JMX support), matters to me...
>
> I can understand. Usually, you lose interest in a project as soon as it
> does whatever you want it to do :)
> There are some exceptions, but I really can understand that.
Or you loose interest when you see that no matter what you do, noone even
listens to what you say...
>> I want, and I'm getting there, only a servlet container able to handle some
>> 10/15 millions servlet-based requests/day. Therefore also approaches such as
>> JNI are definitely out for high availability approach...
>
> Load balancing with node failure tolerance (like the one provided by JK)
> could help there.
> Did you look at JK 2 at all ?
Yes, I did. And in my opinion, it sucks. But my spare cycles are limited to
cram out what's wrong with it... I'll just be silent, as I've always been,
and do what matters to me: take 4.0 and put it in production...
>> Given the latest developments, I seriously don't think I want to be carrying
>> on with TC5.0 anymore, I'll just (as always) do what matters to me, and if
>> it works for me, I'm set...
>
> I'd like to keep you involved if I can.
I've been here for the past 6 years, going "out" is not an option... Doing
what matters to me, instead, is a very viable one...
Pier
--
[Perl] combines all the worst aspects of C and Lisp: a billion of different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
