Well, I'll grant the majority of your points, and even allow how the combination of the web server and the servlet engine could be considered "the application". I still think this is a bad idea, and here is my reasoning.
Before anyone writes this kind of thing they should examine a representative number of web applications and find out how many would actually benefit. I.E. how many "web applications" have significant amounts of static data within their context. To know the true effect, it would further be necessary to have some feel for how much overhead looking at each request and routing it correctly would add. Remember that this new code would now add new overhead to every request that was destined for a servlet. Additionally, you would have to have some approximation of how many web applications use constructs that would totally defeat the module. I.E. filters mapped to /*. I think a lot of people using filters are doing this. In my applications, the vast majority of CPU time and energy is spent on database queries, and creating output. I have very little "static" content within my "application" directory. Perhaps a few icons. The performance benefit of handing those requests to Apache versus Tomcat is minimal and would not be noticed. I would probably get a much more noticeable performance increase by optimizing queries, output creation, etc. It seems to me that if your "Application" design has a great deal of static content within the web application path it would be much simpler, and even less overhead to simply place that static content in a plain static directory and have it served by Apache. Why even have the overhead of a modules that sorts out the requests? While I have to say this breaks the Servlet API deployment guidelines it would be justified. I don't think an application of this nature (high ratio of static content to active content) is the kind that would have to be deployed to a large number of servers. If it did, it would most likely be in a clustering scenario where you would use different methods to roll out changes anyhow. Its your choice. If you think this is really a superior idea, then by all means go ahead and work on it. Personally, I would like to see fewer, but more robust connectors rather than more connectors that are not as solid, but that's my point of view. -----Original Message----- From: Endre Stølsvik [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 2:22 AM To: Tomcat Developers List Subject: Re: [4.1.23] Deprecating mod_webapp On Wed, 19 Mar 2003, George Sexton wrote: | From a purely practical standpoint, that would be terribly complicated. | Mod_webapp would have to read and fully understand the web.xml and all of | the servlet mappings. This is made even more impossible by the addition of | filters to the Servlet API. Impossible?!? | How can mod_webapp even begin to guess at the hidden logic contained | within a filter? Well, it would have to forward requests that were filtered, OF COURSE, since that includes bytecode. | It is totally impossible. It's not clear to me that you could feasibly | implement this kind of front end and incur less overhead that simply | passing the request to the servlet engine. Even if you could, at the end | of the day, it would still be non-compliant because the last sentence of | the second paragraph of section 3.1 of the Servlet API 2.3 Spec says: | | "all requests that begin with the /catalog request path, known as the | context path, are routed to the web application associated with the servlet | context." Read: "web application". Not "Servlet Container". If you absorb the fact that Apache and Tomcat would _work together_ combining forces as being the "Servlet Container", then the above statement would hold true. One does encryption (read: SSL) on the Apache side, even though you have to forward parts of that to Tomcat. This is just as "deviant" from the specs you're referring to, as, considering the web.xml, apache serves static files himself, not bothering his "java-executing" part of the (combined) Servlet Container to do this.. | | I quoted this exact spec to a client because they wanted to do what you | propose, only their engine is not smart enough to parse the web.xml. they | wanted me to rename all of my pages to end in ".jsp" so that it would get | forwarded. What's the idea here?! | | To be compliant, the spec must be fulfilled. ALL requests for the context | path must be forwarded to the application. Read again: "THE APPLICATION". Right. Running in "the Servlet Container". WHICH IS the Apache+Tomcat COMBINATION when you run it with mod_WHATEVER inside of Apache. How would you interpret a Servlet Container that was coded exclusively in C++, not having any "normal" JVM, simly acting as the VM itself by interpreting bytecode? And then, what if you split these thing slightly apart, using a (standard) JVM to execute the bytecode? And then, having the JVM run standalone, using a communication channel of some sort to make it run the bytecodes? .. And then, finally, thought; what the hell, lets just use Apache and Tomcat instead?? | To do otherwise is not compliant with the spec. A specification is like | a map through a mine field. You must do precisely what it says, without | expansion, or interpolation. Thanks for elaborating on spec. interpretation. -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
