cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [OT rant] there must be some way out of here...
Date Wed, 05 Feb 2003 11:47:30 GMT
Miles Elam wrote:
> Stefano Mazzocchi wrote:
>> I'll never use Tomcat again. Period. The phylosophy behind it (big 
>> servlet engine, light http stack on top) is plain wrong. 
> I'm confused...  One of the features of the newest iterations of Tomcat 
> is jndi lookups without the whole of EJB behind it.  Data sources, 
> variables, et al. in a standard (for Java) interface.  How is having 
> Cocoon handle it (through Avalon by proxy) better than having the engine 
> handle it?

Tomcat was sold to us JServ developers as the Servlet 2.1 reference 
implementation for the servlet API. Then, they started sneaking JSP into 
that (did you notice that you get JSPs for tomcat even if you don't want 
them nor use them?), now they start sneaking JNDI in? what if I don't care?

My point is: the servlet API is a *very* simple API, every servlet 
engine which is bigger than 100Kb in size is doing something wrong.

Avalon is a server framework. Tomcat should be the servlet engine, the 
JNDI datasource should be another avalon block and both will cooperate.

But the tomcat development community believes there is only one way of 
doing things, Sun's. I'm sick of this and almost *all* others who made 
the Servlet API a reality.

> This actually brings up another question as I could not find the answer 
> in the archives.  What does the Avalon component manager buy us that a 
> jndi lookup cannot considering the easier migration path from one simple 
> jndi lookup implementation to a more advanced (J2EE-backed) jndi lookup 
> implementation without mucking with too much underlying code (they are 
> all components, right?).
> Not trying to start a fight.  I'm honestly curious.

In Avalon-dev there are *tons* of email discussions about why JNDI was 
not capable enough for what Avalon was trying to do. Berin, do you have 
pointers to those discussions?

>> Tomcat is getting bigger and slower every day and must do only one 
>> stupid thing (connect a URI to a servlet, dah!) that we were able to 
>> do in jserv with some 120Kb of java code. Talking about flexibility 
>> syndrome. Hello? we already have a damn good web server!!! just 
>> because you can't configure it doesn't mean you have to rewrite one 
>> from scratch. get a life. 
> And handle servlet filters and implement the HTTP 1.1 spec in totality, 
> right?
> As far as HTTPd is concerned, it's a web 

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.

> 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 


>  mod_gzip?  Is it really 
> so much more efficient than a compression servlet filter? 

who cares, this is not the point.

> Is it really 
> more efficient that a filter could be?  mod_speling?  Doesn't that start 
> to fail when the files aren't static?  How would you map this to the 
> sitemap?

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!

> It can't be web serving speed with the non-blocking I/O available in 
> Java 1.4.

no it's not speed, damn it. Who cares about http speed if your stinking 
database is taking two seconds to execute a query?

It's about community, support, talent of thousands who worked on it.

Java infected people with the concept that WORA equals "pure java" 
equals "reinvent the wheel everytime".

And tomcat is build on top of that concept!

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?

>> Its connectors win the nobel price for cryptic configuration files and 
>> absent documentation (the first who says that cocoon docs sucks will 
>> have to figure out how to compile tomcat and connectors from source 
>> before being allowed to speak again) 
> 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?)

> I am honestly confused.  I have no affiliation with the Tomcat team 
> except for filing a bug once.  Private mail or public is fine for a 
> response, but I am somewhat at a loss for all this anger.

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.

> 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]

> Once again, not trying to start a fight.  I honestly would like to know.

Hope this gives you more information.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine neccesitate [William of Ockham]

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

View raw message