Re: Rendering JSP files through Apache
On 09/04/2015 19:50, George Sexton wrote: Chris On 4/9/2015 10:06 AM, Christopher Schultz wrote: Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says: /A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext.// / My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. Can you help me understand why that's not the case? It only applies to requests that reach the WebContainer (in this case Tomcat). What happens before that in terms of reverse proxies is out of scope for the Servlet spec. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 3:06 PM, George Sexton wrote: On 4/9/2015 12:58 PM, Caldarale, Charles R wrote: From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. The problem is then that as a system, the container isn't compliant. No, it's the *system* that is broken. The container itself is doing exactly what it is being told to do. If you're not telling it to do the correct things, that's on you, not on the container. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I suppose it's like eating an apple. At what point does the apple become you? Once it's inside you, when your body can start processing it. Just like the request must get inside the container for it to be processed IAW the spec. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 10:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind What I'm saying is that having httpd handle request for .html and everything else handled by the servlet container violates section 4.1 of Java Servlet Specification 3.0. The issue is not the servlet handling the request for .html. The issue is that if the deployment descriptor has an explicit mapping for /context/foo.html, and the web app is never presented with the request because it's being done at the higher level of Apache httpd, then it breaks the web app. httpd is given the request for /context/foo.html, and there is no corresponding file, and the web app is broken. You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. . - -chris -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
Chris On 4/9/2015 10:06 AM, Christopher Schultz wrote: Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says: /A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext.// / My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. Can you help me understand why that's not the case? It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX /OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8 +zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5 bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78 LDSuJI5jc5NsbeMHFLMS =Fb2W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
RE: Rendering JSP files through Apache
From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/2015 12:18 PM, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For And the line above clearly states Web server. Now the next question is, what is a Web server? - From a browser's point of view, that's whatever serves up a URL that select. - From a systems point of view, that can be: 1. a paired hardware load balancer that handles SSL plus 2. a group of Apache web servers that handles PHP, Perl, etc. plus 3. A collection of Tomcat servlet containers for JSP / Servlets, etc. plus 4. A database farm - From a component point of view, that can be: 1. hardware load balancers 2. multiple Apache HTTPD servers 3. possible authentication / authorization servers 4. multiple Apache Tomcat servers 5. multiple database servers (SQL, noSQL, etc.) - From my reading, the specification only applies to item 4 in the components view. Other than that, it's up to the systems architect to get it right. example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVJtLqAAoJEEFGbsYNeTwtmUkH/RFIPAZZHOXsLSOAT4PEl6Lm RMuLnGWztFMR9ITc6DIikjRV2JIas3If8sCucE85LM/+3GWHDp1/HIJuXB073exZ sWp2GSlS1ZYloyqnHGBq31783LdM/xpj0yrTlWWSYN7iVwxD+fd5dAxBYaFqxoxd kh6DEQUld1ELBku2bXSf/4EcPFgPvhkGjvxbot1DQYO+CurHoFGRAnyrsQ17LJ3m Hzm7fo7If1Gowm5EqNhjqPoSIpz8QHvZG0hZSZxg+B260D6RLbcdqpGuFLOZeOjA WcJy+5dYydOxiF+pIFsA14OmEtPvxQsgQMOdTasskiubY60YcQXzvqZfe/7GnBU= =1PCa -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew, On 4/8/15 8:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. Okay. Just curious: why? How do I accomplish this? - From your other thread, it looks like you have solved this problem. Are you still in fact having trouble? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJncCAAoJEBzwKT+lPKRYcdYP/ieIeV/dyE2N7ymFYso6jy8g UElbANv+2n3KwqfCe+ikDQJBOfXyVwxt1NesDC3vkwFHvvYqNJuMQgJNuDS2HpJz KXAGYDJBIEokj6lcWrhs2bYzDpKwdN7ldUM70wXG4OZ/yrXvrhtHSKnikfGtJoyW EWj1/HnHL21j7Hvzp3uHVrWMUDJbFDf+1BvIJJ/kA5orJ5fy01Tk0s+/BGeMkWuk BotBaokxN4ttX7Z5VFfczEDYkfZ2OlmpaKDURaD2uyITaXy8KQ3SNdViLpyxdBaT 2Nh7cio1wCVfkn4FxkDps9Y9eBTRBHWKfZNyrV9xIPMSGc3soInQ0uWvGTTXyJAd O6LahC/sA2fpT5MIayXUrjNQHOd3gUudrRPRD4O75JRTjPgg05tLiqZcYWkyDD91 BLriXIudPDbTt/Tw6Zq0PXrmTiIPSzdCLUNeznJWJuknhul86vYRs5luFORS1byu lBIZNZq4us5bmHHk9ufME37uwV+P2f5bZAZBOv25XYszNgc1m0PdJxN/A+dOomPJ Q+G52pKRXn+nNV/P2zZ9kZNC09ZnH8FnkzLXHnP9GVzAP2+OQ/klZJWDV3JxAkH7 JES4imdhADRypTntI34rqeN7vYSzQm7WTrbqHDyyXTK6WBtsytipf+dNiWfa10rL ntPsrfPnR9xmRlnEZ4C2 =IXuZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX /OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8 +zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5 bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78 LDSuJI5jc5NsbeMHFLMS =Fb2W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 12:58 PM, Caldarale, Charles R wrote: From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. The problem is then that as a system, the container isn't compliant. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I suppose it's like eating an apple. At what point does the apple become you? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 3:03 PM, George Sexton wrote: On 4/9/2015 10:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind What I'm saying is that having httpd handle request for .html and everything else handled by the servlet container violates section 4.1 of Java Servlet Specification 3.0. The issue is not the servlet handling the request for .html. The issue is that if the deployment descriptor has an explicit mapping for /context/foo.html, and the web app is never presented with the request because it's being done at the higher level of Apache httpd, then it breaks the web app. httpd is given the request for /context/foo.html, and there is no corresponding file, and the web app is broken. You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 09/04/2015 20:18, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. with my Servlet Expert Group member hat on You are misunderstanding the specification. The specification only applies to requests that reach the Servlet Container. (You can safely replace 'Web Server' above with 'Servlet Container' in the text you quote). If you want to be picky about it, even once you reach the Servlet container that quote is not 100% accurate. The container is required (by the HTTP spec that is referenced from the Servlet spec) to reject mal-formed requests with a 400 response before they are passed to a Web Application even if enough of the request is well-formed to determine the intended Web Application. As others have already stated: - The Servlet specification does not care if you put a reverse proxy in front of the Servlet Container. - The Servlet specification does not care if a reverse proxy routes requests that the Servlet Container could correctly handle elsewhere. Once you insert a reverse proxy (or a load-balancer, or a firewall, or...) you have a larger system and it is up to the designer of that system to ensure that the components of the system work together as desired. Yes, it is possible to break an application by inserting a reverse proxy but that is just a broken system, not an specification compliance issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. This is a Linux environment with Apache version 2.4.6 and Tomcat version 7. Thanks Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone P (914) 765-3206 | Fax ( (914) 765-3095 | andrew.leg...@mbia.com -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, April 08, 2015 5:34 PM To: Tomcat Users List Subject: Re: Rendering JSP files through Apache Leggio, Andrew wrote: I have the following being used in my conf file: IfModule mod_proxy_ajp.so ProxyPass / ajp://localhost:8009/ /IfModule Does this actually direct jsp files to use Tomcat? That is a funny way of putting it. What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009. Now whether this is actually what is happening or not, is anyone's guess so far. Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong. The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it. -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 3:18 PM, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There is no violation of this if a request never reaches the container in the first place. The spec only applies to the servlet container itself, not to the overall system of which it might be a part. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Rendering JSP files through Apache
From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache The problem is then that as a system, the container isn't compliant. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I think you're way, way off base. The servlet spec does not, in any way, attempt to define the semantics of a system; it is explicitly confined to the actions of a servlet container. If a system administrator chooses to deploy multiple components within a system, it's up to that admin, not the servlet spec, to decide which components are involved in any given flow. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
Leggio, Andrew wrote: I have the following being used in my conf file: IfModule mod_proxy_ajp.so ProxyPass / ajp://localhost:8009/ /IfModule Does this actually direct jsp files to use Tomcat? That is a funny way of putting it. What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009. Now whether this is actually what is happening or not, is anyone's guess so far. Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong. The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Rendering JSP files through Apache
This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? This is a Linux environment with Apache version 2.4.6 and Tomcat version 7. Thanks Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone P (914) 765-3206 | Fax ( (914) 765-3095 | andrew.leg...@mbia.com -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, April 08, 2015 5:34 PM To: Tomcat Users List Subject: Re: Rendering JSP files through Apache Leggio, Andrew wrote: I have the following being used in my conf file: IfModule mod_proxy_ajp.so ProxyPass / ajp://localhost:8009/ /IfModule Does this actually direct jsp files to use Tomcat? That is a funny way of putting it. What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009. Now whether this is actually what is happening or not, is anyone's guess so far. Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong. The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it. -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
