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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
