Miles Elam wrote:
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?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?
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?).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?
Not trying to start a fight. I'm honestly curious.
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.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 PHPbecause cocoon simply produces the content and somebody else does the transport.
and Perl (directly generating HTML) are suboptimal methods for creating sites on a large scale, why use HTTPd at all?
SoC.
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?
there was mod_jserv. it was hard to configure, but we wrote docs and people were happy.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.
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 gcjthat'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]
doesn't have the graphics APIs down yet.
Once again, not trying to start a fight. I honestly would like to know.
Hope this gives you more information. -- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine neccesitate [William of Ockham] -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
