tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Mod_ajp initial
Date Mon, 26 Jul 2004 19:17:33 GMT
Mladen Turk wrote:

> Costin Manolache wrote:
>>Mladen Turk wrote:
>>>If I make a design flaw, and the entire project gets 
>>unusable, it will 
>>>make it just something like mod_java, mod_warp, mod_jk and 
>>mod_jk2 are... Dead.
>>>Nobody will get hanged for that.
>>I don't think the goal is to accumulate more mod_warp, 
>>mod_jk, mod_jk2 - but to learn from the past errors and do 
>>something better.
> OK then, do you have some other proposition, or just saying what we all said
> discussing this subject.
> AFICR you said that you will have something to share, and I'd love to see
> some other, perhaps better ideas.

No, I'm trying stuff on java side.

And just like with code - I don't think we are missing propositions or 
ideas. What is missing is an agreement over what features we are going 
to support ( and more exactly - not support ), as well as a clear plan 
on how to support them without spaghetti.

I think we do have agreement on droping IIS/iPlanet. We had agreement on 
droping pluggable protocol - but that's now back with the discussion on 
mod_proxy ( which also involves pluggable protocol ).

>>Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and 
>>requirements ( == goals ).
>>And at least in apache2 I remember they did spent the time to discuss 
>>this and figure out the best design ( and quite a few "creative" 
>>solutions were not accepted ). Take a look at apache filters, or APR.
> We are discussing too, right? And if you follow the discussion, you will
> find enough 'design leads'.
> There is nothing in the source tree jet, and the thread is named 'initial'.
> After all, I wrote that initial code in a single afternoon, so it's not such
> a big deal.

Yes, we do have plenty of connectors, and most were written very fast - 
   mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy.

Having a 6th codebase - especially in the context of the growing 
agreement over mod_proxy as a long-term solution - is not what is missing.

My concern is that we are just repeating the history of the first 4 
connectors - by writting some initial code that solves the easy problem 
( sending requests to tomcat ), and hoping the rest can be added without 
getting back to spaghetti.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message