cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <mi...@pcextremist.com>
Subject Re: [OT rant] there must be some way out of here...
Date Wed, 05 Feb 2003 21:45:56 GMT
Stefano Mazzocchi wrote:

>> And handle servlet filters and implement the HTTP 1.1 spec in 
>> totality, right?
>>
>> As far as HTTPd is concerned, it's a web 
>> server...er...proxy...er...connection hub...er... 
>
>
> no, it's a rock-solid HTTP stack with modular capabilities. It's up to 
> you on what modules you add. From an architectural perspective HTTPd 
> is a framework for HTTP-based functionality. 


And this is what you see for servlet engines I assume: a servlet API to 
HTTP framework?  The fact of the matter is that the Tomcat developers 
are doing much the same thing that Apache did when they split off from 
the CERN server, right?  Are you sure that your love of HTTPd isn't 
biasing your argument just a little?  I understand that this is a rant, 
but still...

Is your main criticism that JSP functionality isn't pluggable?  
(Although it is if you remove jasper.jar and any reference to Jasper and 
JSPs in the config files.)

I guess I'm the only one who doesn't think that HTTPd's config files are 
all that clear.  If it weren't for the comments, I'd be completely lost 
sometimes -- or at least as much or more than the first time I saw 
Tomcat's configuration files.  Please don't forget that you've had YEARS 
to get familiar with HTTPd.

(And no, I'm not arguing that HTTPd is bad.  That would be a fool's 
cause.  But some of the fire and brimstone smells a bit like code religion.)

>> The one thing I miss about having Apache in front of my servlet 
>> engine (I currently run with Tomcat bare) is the reliability 
>> associated with forking and recycling child processes.  Honestly, if 
>> Cocoon is already demonstrating that PHP and Perl (directly 
>> generating HTML) are suboptimal methods for creating sites on a large 
>> scale, why use HTTPd at all?
>
>
> because cocoon simply produces the content and somebody else does the 
> transport.
>
> SoC. 


I'm afraid you misunderstood my statement.  I only brought up PHP and 
Perl as examples of some of the most-used modules in HTTPd.  I'm not 
suggesting that Cocoon should listen on port 80.  In my case, Cocoon is 
the content and Tomcat is the transport.  My question was that if Tomcat 
(or Jetty, Resin, etc.) is acting as the transport and the site is based 
upon technologies covered by Cocoon and/or other servlets, what 
important role does HTTPd play?

Pier answered my question with a lot of great information such as 
multi-process robustness, fall-back error pages when/if a JVM goes down, 
etc.  However, I noticed one hole in the setup he proposed: URI 
permanence.  You'll note that he created a "/static/" mapping for 
content that Apache should serve raw instead of passing the request to a 
servlet engine.  What does "/static/" do but tie your implementation to 
your URI -- precisely the type of thing Cocoon 2 was made to avoid.  
What does the fact that I have a picture of a train crossing have to do 
with "/static/images/traincrossing.jpg"?  I might as well have a URI 
like "/images.php?name=traincrossing".

When it comes down to it, I'm trying to wrap my head around an optimum 
solution and not the optimum solution with HTTPd, Tomcat, or even Java.  
If HTTPd (with its robustness) had an expressive sitemap, I would be 
singing in the streets right now.  The conversations about having 
non-blocking I/O bit blast the Cocoon cache to the output stream really 
got my gears turning, but that still misses HTTPd's robustness.  In the 
end, I'm stuck looking at HTTPd doing nothing except pump requests to 
multiple backend JVMs, and that just seems "good enough" instead of 
"good" to me.

> I never advocated the use of *all* httpd modules to connect to cocoon. 
> What I advocate is that *ONE* HTTP stack is good enough and we just 
> need a thin HTTPd->java layer to connect our cocoon to it and tomcat 
> is not thin at all! 


This is predicated on the assumption that HTTPd is necessary!  Do you 
understand that you are ensuring that HTTPd be part of the equation and 
not looking from first principles.  I'm not saying you're wrong.  I'm 
asking you to stay objective.  You are advocating a servlet engine 
without any web serving capability because you have already decided that 
HTTPd *must be* the HTTP stack.

> Jserv was built by people who wanted to add java to the http world. 
> Tomcat is built by people who want to add http to the java world.
>
> See my problem?


Yes, but the same statement could be written as:

Jserv was built by people who wanted to add servlets to C.  Tomcat is 
built be people who wanted to allow access to servlets from C.

Having putzed around with the Apache module API, ISAPI, NSAPI, and the 
servlet API, I can see both points of view.  Compared to the others, the 
servlet API is so simple, so easy to use, so intuitive that it's painful 
to even consider the others.  Some of it is the Java language (and the 
fact that C doesn't have true objects).  I don't presume to say that the 
servlet API is perfectly clean -- I don't believe myself to be all that 
delusional -- but it's a damn sight better than most alternatives.  
HTTPd is *very* C-centric in much the same way that Tomcat is 
Java-centric.  Yes, there are C++ "wrappers" for modules, but this is an 
ad hoc addition that isn't codified or standardized at all.  Everything 
but C is a second (or third) class citizen.  Perl?  Ask the folks who 
have been waiting for a stable mod_perl for HTTPd 2.0.

>> Okay, compiling that beast, I'll have to agree.  But aside from 
>> connecting Tomcat to HTTPd, I haven't really found it to be an issue 
>> -- especially with the work done to make a web-based management console.
>
>
> there was mod_jserv. it was hard to configure, but we wrote docs and 
> people were happy.
>
> then came mod_jk and WARs, configurations became a pain and instead of 
> writing docs, they decided to have tomcat autogenerate the 
> configurations for the module. (can you see the tomcat-centricity on 
> this?) 


Ah.  Okay.  Now I'm getting it.  This is an area I've avoided because I 
haven't been using HTTPd, but it's a valid point nonetheless.  Tie-in is 
tie-in.  You want the work done to connect HTTPd to a servlet engine to 
be unified and a single point of development instead of Resin's 
connector, Jetty's connector, Tomcat's connector, etc.

> The anger comes from the fact that all technological decisions in 
> tomcat ruined the work several of us have done over years. And none of 
> us (even working inside sun, as Pier) had the energy to fight stupid 
> moves. 


I remember the clustering docs from the JServ days, but never followed 
up on them in later years (my company went to a non-servlet solution).

So let me see if I'm understanding now.  You aren't angry because Tomcat 
has its own HTTP stack.  You are angry because they seem to be going out 
of their way to keep other HTTP stacks from working with it.  If this is 
the case, you've got me convinced.

>> On another note: does anyone see a future in using something like gcj 
>> to more closely link a servlet engine to Apache HTTPd to regain the 
>> stability areas I mentioned earlier and to avoid the socket 
>> communications?  The only thing that pops out in my head is Batik as gcj
>> doesn't have the graphics APIs down yet.
>
>
> that's not the problem. the problem is interface-based dynamic loading 
> of our Component-oriented programming paradigms. Something that gcj 
> folks probably don't even know it exists. [I'd be happy to be proven 
> wrong, though] 


gcj has dynamic classloading and a linkable interpreter.  I know that 
Tomcat has been successfully compiled to native code with gcj.  
Considering the comments regarding difficulty in compiling Tomcat at 
all, this has got to be worth something.

Looking at the status page (http://gcc.gnu.org/java/status.html), the 
items that stick out as missing are not related to interfaces, but 
rather graphics handling (affects Batik), directory access (affects 
calls to J2EE), and java.text (which would hinder the i18n work).  Since 
I've been casually following the gcj project, I've noticed that 
interfaces have been a major focus at times.

> Hope this gives you more information. 


Indeed!  And I'll go check out the avalon-dev archives for more info on 
the JNDI discussion.

- Miles



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message