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 Tue, 04 Feb 2003 23:06:22 GMT
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?

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.

> 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 
server...er...proxy...er...connection hub...er...  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?  mod_gzip?  Is it really 
so much more efficient than a compression servlet filter?  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?

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

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

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.

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.

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

- 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