RE: [4.1.23] Deprecating mod_webapp
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
RE: [4.1.23] Deprecating mod_webapp
George Sexton wrote: 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 It is a bit late - the code for this kind of thing is already written and used ( in mod_jk and mod_jk2 ). It seems to work fine - and you have the choice of mapping the whole uri space or letting apache handle static files. Since you are in the first use-case - you don't need to worry about the other :-), just like people who want static files served by apache don't have to worry about your use case. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [4.1.23] Deprecating mod_webapp
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. How can mod_webapp even begin to guess at the hidden logic contained within a filter? 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. 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. To be compliant, the spec must be fulfilled. ALL requests for the context path must be forwarded to the application. 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. If you do otherwise, you will at the least blow your foot off. In our case, by scrupulously following the spec, we have an application that has been tested on 6-8 servlet engines with only one small tweak to work around a bug in one of them. Deviation from the specification, even in the name of imagined efficiency is not acceptable. This is particularly true of Tomcat since it has the role of Reference Implementation. From my experience JkMount directice of mod_jk is simpler to use in real environment when you want to split load between Apache and Tomcat, one handling static/php and the other servlet/jsp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: [4.1.23] Deprecating mod_webapp
Remy Maucherat wrote: Hi, I'd like to officially deprecate mod_webapp in Tomcat 4.1.23. +1 :-(( I am using jk2 in 2 FSC products so I prefer that the energies go to one connector instead beeing spread in severals. It is no longer maintained, and will not work with Tomcat 5.0 (at least it won't unless people contribute stuff). That is something I will not make alone because I have _very_ little free time for the next mounths. Remy - 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]
Re: [4.1.23] Deprecating mod_webapp
On Mon, 17 Mar 2003, George Sexton wrote: | It's also horribly broken and not compliant with the servlet API. | Specifically, it doesn't forward all requests within the context to the | servlet engine, but attempts to let Apache fulfill static requests. Isn't that one of the good reasons for having Apache as frontend? Serving (largish) images and other static files (e.g. stylesheets, XML, dtds etc) could be much mor effectively done by Apache, instead of using IPC of some kind to an Java engine, which had to parse and serve the request.. I mean, there are _large_ overheads that could be avoided.. If the mod_webapp served static requests, but honored the web.xml file _completly_, then it would be great, right? -- 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]
RE: [4.1.23] Deprecating mod_webapp
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. How can mod_webapp even begin to guess at the hidden logic contained within a filter? 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. 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. To be compliant, the spec must be fulfilled. ALL requests for the context path must be forwarded to the application. 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. If you do otherwise, you will at the least blow your foot off. In our case, by scrupulously following the spec, we have an application that has been tested on 6-8 servlet engines with only one small tweak to work around a bug in one of them. Deviation from the specification, even in the name of imagined efficiency is not acceptable. This is particularly true of Tomcat since it has the role of Reference Implementation. George Sexton MH Software, Inc. Home of Connect Daily Web Calendar Software http://www.mhsoftware.com/connectdaily.htm Voice: 303 438 9585 -Original Message- From: Endre Stølsvik [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 2:06 AM To: Tomcat Developers List Subject: Re: [4.1.23] Deprecating mod_webapp On Mon, 17 Mar 2003, George Sexton wrote: | It's also horribly broken and not compliant with the servlet API. | Specifically, it doesn't forward all requests within the context to the | servlet engine, but attempts to let Apache fulfill static requests. Isn't that one of the good reasons for having Apache as frontend? Serving (largish) images and other static files (e.g. stylesheets, XML, dtds etc) could be much mor effectively done by Apache, instead of using IPC of some kind to an Java engine, which had to parse and serve the request.. I mean, there are _large_ overheads that could be avoided.. If the mod_webapp served static requests, but honored the web.xml file _completly_, then it would be great, right? -- 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]
Re: [4.1.23] Deprecating mod_webapp
+1 Remy Maucherat wrote: Hi, I'd like to officially deprecate mod_webapp in Tomcat 4.1.23. It is no longer maintained, and will not work with Tomcat 5.0 (at least it won't unless people contribute stuff). Remy - 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]
RE: [4.1.23] Deprecating mod_webapp
It's also horribly broken and not compliant with the servlet API. Specifically, it doesn't forward all requests within the context to the servlet engine, but attempts to let Apache fulfill static requests. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:34 AM To: Tomcat Developers List Subject: [4.1.23] Deprecating mod_webapp Hi, I'd like to officially deprecate mod_webapp in Tomcat 4.1.23. It is no longer maintained, and will not work with Tomcat 5.0 (at least it won't unless people contribute stuff). Remy - 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]
