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