Re: AJP13 Connector and JKOptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/19/2009 2:46 PM, Pete Helgren wrote: I use Freemarker (and a smaller framework called niggle) as my servlet template engine and the only other thing I reference is a resource base in the servlet context like this: init-param param-nameRESOURCE_BASE/param-name param-value../../templates/param-value /init-param This just tells Freemarker where to find your templates. It has nothing to do with the layout of your URIs. Perhaps niggle is doing the context magic for me but I haven't run into this issue in other deployments, just this one. And, as you indicate, it could be dumb luck (wouldn't be the first time!) I think it is luck: when deployed in a context, all the relative links work. You're now finding that relocation isn't working out well. AFAIK, Freemarker does not include a standard way to format URLs all in one shot. I thumbed-through the documentation and it wasn't entirely clear to me how to do it. I suspect someone well-versed in Freemarker will be able to interpret my JSP syntax into usable FTL. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmeq0kACgkQ9CaO5/Lv0PA9RACfRAZjqSvKZX+SI3ryqI1GB19u A8oAniZx7bMhrPrAgS80fXl+/qAtCIBi =nqs0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/20/2009 12:25 AM, Pete Helgren wrote: Chris suggested that I use JKMount /context/* but not knowing exactly how that would play when the context was ROOT With JkMount /context/*, a ROOT-deployed application won't work without other configuration. If you'd really like to do that, you can search the archives for uses of mod_rewrite to change the name of the context portion of the URL (or even remove it). I believe mod_proxy_ajp makes this even easier because it can mount and rewrite all in one step: ProxyPass /context ajp13://localhost:8009/ Note the lack of context at the end of that second URL. I went ahead and installed the application at the /asaap3 context so the final JKMount entry was /asaap3/* . That works! And I understand why. All of the folders like /templates /scripts /images /stylesheets are off of the context so now the /asaap3/ASAAP pages have the correct url mapping. The anyhost/asaap3/ASAAP returns the correct path to anyhost/asaap3/images/bg_hdr_logo.gif So you can not only find the correct page, but the correct images as well. The slightly longer URL isn't an issue. /asaap3/ASAAP vs /ASAAP isn't a problem. You can also map / to a servlet if ASAAP is actually your controller servlet or something. Then your URL would be anyhost/asaap3/. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmerHMACgkQ9CaO5/Lv0PAzGQCgqofo8YlNMcu/BxipfDFo6jlk qMkAn3xxrz0FiDwUA+x0D5fHIkcLDvIT =ZHoG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Thanks. I *will* dig deeper and experiment a bit when I get the time. I doubt that Freemarker had much impact on the final rendering and the context since it is just a templating tool, not specific to web apps. Niggle (which uses Freemarker) might have something to do with it and we had a developer that tweaked Niggle some, but that was a *long* time ago (I don't think Niggle has seen any action since 2002). I really hadn't looked very carefully at deployment issues so this is now on my list to understand more completely so I don't run into any issues on future deployments. I appreciate the pointers and the patience. There is always something more to learn in this business and it's always good to have my assumptions challenged which in this case were all wrong. Pete Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/20/2009 12:25 AM, Pete Helgren wrote: Chris suggested that I use JKMount /context/* but not knowing exactly how that would play when the context was ROOT With JkMount /context/*, a ROOT-deployed application won't work without other configuration. If you'd really like to do that, you can search the archives for uses of mod_rewrite to change the name of the context portion of the URL (or even remove it). I believe mod_proxy_ajp makes this even easier because it can mount and rewrite all in one step: ProxyPass /context ajp13://localhost:8009/ Note the lack of context at the end of that second URL. I went ahead and installed the application at the /asaap3 context so the final JKMount entry was /asaap3/* . That works! And I understand why. All of the folders like /templates /scripts /images /stylesheets are off of the context so now the /asaap3/ASAAP pages have the correct url mapping. The anyhost/asaap3/ASAAP returns the correct path to anyhost/asaap3/images/bg_hdr_logo.gif So you can not only find the correct page, but the correct images as well. The slightly longer URL isn't an issue. /asaap3/ASAAP vs /ASAAP isn't a problem. You can also map / to a servlet if ASAAP is actually your controller servlet or something. Then your URL would be anyhost/asaap3/. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmerHMACgkQ9CaO5/Lv0PAzGQCgqofo8YlNMcu/BxipfDFo6jlk qMkAn3xxrz0FiDwUA+x0D5fHIkcLDvIT =ZHoG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): [...] Hi again. I haven't looked into the question of the image URLs very closely, but one thing you have to keep in mind is : - the server, unless you explicitly do something for that, is not going to peek /into/ the pages that it serves and go modify links inside of them. It will serve them as they are, period. In other words, as the pages are on the disk (or are generated by a webapp), so will the webserver send them to the browser. Mull over this until you are really convinced, then go to the next step. - the actor who is going to interpret a relative link like images/mypic.gif found inside a page is /the browser/. The browser knows from which URL the page that it is currently rendering, comes from. E.g. it knows (or thinks it knows) that the current page came from, say, http://thathost:thatport/somedir/abc.html;. Mull again.. - when the browser, in this page, finds a link like images/mypic.gif, it is going to fill in the missing part, on the base of the current page's origin. In other words, it will take the current page's URL http://thathost:thatport/somedir/abc.html;. then remove the trailing abc.html, and replace that by the relative link images/mypic.gif, thus giving http://thathost:thatport/somedir/images/mypic.gif;. And then it is going to issue a brand-new request to the server for http://thathost:thatport/somedir/images/mypic.gif; (1) - Now if it so happens that this link that the browser is building for the image, when issued to the server, does not return what you expect, then tough ! It means that your way of putting links in pages, is not compatible with your setup. What I mean is that, in terms of these relative URLs, it is not the server that does something special. The server is not involved. Only the content of your pages, and the browser, are involved. If you want the server to be involved, and go modify those links in the pages /before/ returning them to the browser, then you have to add a special filter at the server level, which will read all outgoing pages, find the links in them, and change them to something else. That exists, but it is something you have to /add/, the server won't do that on its own. (1) for the purists : really, the browser is going to connect to thathost:thatport, and then send over that connection a request for /somedir/images/mypic.gif. But it's easier to explain it as above. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
On 19.02.2009 05:35, Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. What is MyDomain? Some placeholder you chose instead of showing us the real value, or is it actually sying MyDomain? If so, where does that come from? The config you showed us doesn't contain a glimpse of MyDomain. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
It is a placeholder. Unfortunately, every time I paste a link in an email and send it to the list I get it returned as undeliverable by the Apache List Software as spam. I get it back with this: There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. valadd.com #5.5.0 smtp;552 spam score (5.7) exceeded threshold So I stopped trying to send links in the emails. It does resolve to h t t p : // w w w . a c o r r e c t d o m a i n n a m e . c o m /images/bg_hdr_logo.gif I would post the real link if the firewall allowed 8080 traffic through because then you could see the difference between the 'domain reference'/images/bg_hdr_logo.gif and the 'domain reference':8080/images/bg_hdr_logo.gif. The 8080 URL displays fine. The one at :80 displays nothing but a missing image. I also tried Andre's suggestion to use Location /MyApp SetHandler jakarta-servlet /Location and it made no difference. The Tomcat application is installed at ROOT so tonight I may try installing it at a different context and change the JKMount point and see if that makes a difference. I do have an identical application installed on a different server using Tomcat and Apache at a different context and behind ISA server and it works fine. I am just trying to get to the bottom of why this particular application instance installed at ROOT on Tomcat is responding OK and rendering OK at :8080/MyApp but through AJP it has no images at :80/MyApp. Pete Rainer Jung wrote: On 19.02.2009 05:35, Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. What is MyDomain? Some placeholder you chose instead of showing us the real value, or is it actually sying MyDomain? If so, where does that come from? The config you showed us doesn't contain a glimpse of MyDomain. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td - 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: AJP13 Connector and JKOptions
On 19.02.2009 15:24, Pete Helgren wrote: It does resolve to h t t p : // w w w . a c o r r e c t d o m a i n n a m e . c o m /images/bg_hdr_logo.gif I would post the real link if the firewall allowed 8080 traffic through because then you could see the difference between the 'domain reference'/images/bg_hdr_logo.gif and the 'domain reference':8080/images/bg_hdr_logo.gif. The 8080 URL displays fine. The one at :80 displays nothing but a missing image. OK, I can now see the original image link. What was the original page URL, that you were calling in your browser? Originally you wrote about /MyApp, but below you write about having it deployed as the ROOT context, so your JkMount would be something like JkMount /* myappw Was the page retrieved via the URL h t t p : // w w w . a c o r r e c t d o m a i n n a m e . c o m / or via a different URL? mod_jk automatically forwards server name and port used to contact httpd to the Tomcat connector, and when the webapp asks tomcat how it got contacted it will answer with the originl httpd data. That's what one wants for a reverse proxy, and what's build in into the AJP protocol used between httpd and Tomcat with mod_jk. You can overwrite this automatic game by setting proxy-Attributes on the AJP connector, but that's very unusual and should only be used, if for instance there is yet another reverse proxy in front of your httpd and thus the httpd/mod_jk already do not know the correct host name, port and protocol. The Tomcat application is installed at ROOT so tonight I may try installing it at a different context and change the JKMount point and see if that makes a difference. I do have an identical application installed on a different server using Tomcat and Apache at a different context and behind ISA server and it works fine. I am just trying to get to the bottom of why this particular application instance installed at ROOT on Tomcat is responding OK and rendering OK at :8080/MyApp but through AJP it has no images at :80/MyApp. Try rethinking: do you have a server name problem, a port problem or a context path problem. I had the impression you had either a server name or a port problem. Then the ROOT context will not help. Regards, Rainer Pete Rainer Jung wrote: On 19.02.2009 05:35, Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. What is MyDomain? Some placeholder you chose instead of showing us the real value, or is it actually sying MyDomain? If so, where does that come from? The config you showed us doesn't contain a glimpse of MyDomain. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/18/2009 11:35 PM, Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. This is a risky URL because it is not rooted in the webapp's context path. If your page moves (or the target GIF moves) you're image won't work. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td So, looking at the page that DOES display correctly I see this for the image properties: localhost:8080/images/bg_hdr_logo.gif Note the leading /. I'll bet the URL of the page is something other than /somepage.html. It's probably more like /subdir/somepage.html. Your relative URI will not work in this case. Apache has no other role except to pass through the traffic to Tomcat. [snip] Location /MyApp SetHandler jakarta-servlet /Location This will certainly help. If you want Tomcat to serve your static content, you'd better map that static content to Tomcat instead of allowing Apache httpd to attempt to serve it. I suspect you don't have an Alias for /MyApp. Andre's suggestion to use Location is only because Location essentially provides a URI prefix which you weren't doing. Your JkMount just said map the exact URI /MyApp to Tomcat. Any other URIs (like /MyApp/foo) won't go to Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmddX0ACgkQ9CaO5/Lv0PCFHACePXwv1b7lse1LzRc8JmPTOT4S YjoAmwfgHewdb7mHMJBh3HA2CYuoasw6 =Optb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Thanks Rainer. I have thought about both server name and port issues and I can't see where they might be part of the problem. I may try on my own development PC to see if I can replicate the issue. On the host server a localhost/MyApp generates the same broken link/image issue as the full mydomain/MyApp URL. I tried them both on the server itself because I was worried that a firewall/DNS issue might be getting in the way. But both localhost/MyApp and myDomain/MyApp display the same behavior. Going to localhost:8080/MyApp renders fine also MyDomain:8080/MyApp renders fine on the host server. If you want to actually see the broken version go to altusschools.k12.ok.us/ASAAP using http and see the problem. A working version would be (www.) asaap.com/asaap3/ASAAP. I assume you can figure out the correct URLs for http (sorry I have to munge them to get past the spam filtering). In the broken version, the application is installed at ROOT with the following context in web.xml: servlet servlet-nameAsaapServlet/servlet-name servlet-classcom.valadd.asaap.selfserve.AsaapServlet/servlet-class /servlet servlet-mapping servlet-nameAsaapServlet/servlet-name url-pattern/ASAAP/url-pattern /servlet-mapping I am using JKMount /ASAAP asaap3w in Apache Thanks for the ideas and the help. I can't make immediate changes to the Apache instance and bounce it because the server is in production and I have a very limited testing window late in the evening. Pete Rainer Jung wrote: On 19.02.2009 15:24, Pete Helgren wrote: It does resolve to h t t p : // w w w . a c o r r e c t d o m a i n n a m e . c o m /images/bg_hdr_logo.gif I would post the real link if the firewall allowed 8080 traffic through because then you could see the difference between the 'domain reference'/images/bg_hdr_logo.gif and the 'domain reference':8080/images/bg_hdr_logo.gif. The 8080 URL displays fine. The one at :80 displays nothing but a missing image. OK, I can now see the original image link. What was the original page URL, that you were calling in your browser? Originally you wrote about /MyApp, but below you write about having it deployed as the ROOT context, so your JkMount would be something like JkMount /* myappw Was the page retrieved via the URL h t t p : // w w w . a c o r r e c t d o m a i n n a m e . c o m / or via a different URL? mod_jk automatically forwards server name and port used to contact httpd to the Tomcat connector, and when the webapp asks tomcat how it got contacted it will answer with the originl httpd data. That's what one wants for a reverse proxy, and what's build in into the AJP protocol used between httpd and Tomcat with mod_jk. You can overwrite this automatic game by setting proxy-Attributes on the AJP connector, but that's very unusual and should only be used, if for instance there is yet another reverse proxy in front of your httpd and thus the httpd/mod_jk already do not know the correct host name, port and protocol. The Tomcat application is installed at ROOT so tonight I may try installing it at a different context and change the JKMount point and see if that makes a difference. I do have an identical application installed on a different server using Tomcat and Apache at a different context and behind ISA server and it works fine. I am just trying to get to the bottom of why this particular application instance installed at ROOT on Tomcat is responding OK and rendering OK at :8080/MyApp but through AJP it has no images at :80/MyApp. Try rethinking: do you have a server name problem, a port problem or a context path problem. I had the impression you had either a server name or a port problem. Then the ROOT context will not help. Regards, Rainer Pete Rainer Jung wrote: On 19.02.2009 05:35, Pete Helgren wrote: What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. What is MyDomain? Some placeholder you chose instead of showing us the real value, or is it actually sying MyDomain? If so, where does that come from? The config you showed us doesn't contain a glimpse of MyDomain. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td - 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: AJP13 Connector and JKOptions
Pete Helgren wrote: [...] Pete, I really think you should re-read my previous answer. I did a quick check on the page you indicated, using Firefox and it's LiveHttpHeaders add-on, and the result in summary is : The first link to the page, ending in /ASAAP , works fine. But subsequently, the browser is requesting URLs like : GET /stylesheets/value.css HTTP/1.1 GET /images/bg_hdr_logo.gif HTTP/1.1 etc.. and getting consistently 404 Not found responses. And, these responses come from Apache, not Tomcat. And, it is normal because : In the configuration of mod_jk in Apache, either with the JkMount directives or the Location section that you tried, what you are actually saying to the Apache mod_jk module is : 'grab all requests that start with /ASAAP, and send them to Tomcat to generate the content for them; then grab the content back as Tomcat generates it, and return that to the browser. And that's fine and it also works fine for your starting page. But, because of the way the relative links to stylesheets and images are , in the html page that Tomcat returns, the following requests from the browser are for URLs like above, /which do not start with /ASAAP/. Thus, mod_jk could not care less about these, and lets Apache itself generate the content for them. So now Apache is looking in its own DocumentRoot (probably something like /var/www/docs, for an object that matches the path /images/bg_hdr_logo.gif, and it does not find it. So it returns a 404 not found. Apache has no reason at all to go look for these objects in Tomcat's application directory (which is not at /var/www/docs but somewhere else) to go find these objects, and it will not. Why does it work when you access Tomcat directly (on port 8080) ? Because then, your browser is getting the initial page from the Tomcat at http://yourhost:8080/ASAAP;. So when the browser sees, in that page, a relative link like images/bg_hdr_logo.gif, it will issue a new request to http://yourhost:8080/images/bg_hdr_logo.gif; (thus to Tomcat). And, presumably, your Tomcat configuration is such that it will find, in Tomcat's document root, an object that matches the URL /images/bg_hdr_logo.gif. To correct this, make the following experiment : In the html page that Tomcat returns for the URL /ASAAP, change the relative link to an image, from this : img src=images/bg_hdr_logo.gif width=254 height=132 border=0 to this : img src=/ASAAP/images/bg_hdr_logo.gif width=254 height=132 border=0 and then try again. It should not change anything for a direct access to Tomcat on port 8080. But now, mod_jk at the Apache level will consider this a URL that it should handle, and will pass it to Tomcat. (And if the above does not work, then I'm missing something at the level of your Tomcat configuration). Now, the above does not solve all your problems, but it indicates where the issue is. There are several possible solutions to the problem, but that depends on your setup and what ultimately you want to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Thanks Andre. And, I DID carefully read your original post and I had some inkling that the problem had to do with context vs the JKMount directive. I had concluded that Apache had difficulty serving the images and I figured that the JKMount reference somehow was in the middle of it. References with /ASAAP were being rendered . Those without /ASAAP weren't rendering. What I am after is what is wrong with the current config in Apache or Tomcat that is breaking the references since another application works fine with that reference structure. In the other example I posted that DOES work, the JKMount is /asaap3/ASAAP and the Tomcat context is asaap3 with servlet url being /asaap3/ASAAP. Not sure why the images in that case *are* being found . The Apache configuration is slightly different in that it is using a virtual host entry for that application . It could be the JKAutoAlias entry that points to the tomcat webapps folder or perhaps the Options +FollowSymLinks directive. Those are the only differences in server configuration between the application that works and the one that doesn't. I have added and removed BOTH entries to the Apache configuration that doesn't work without success. I understood your description of the problem until you got to the part where you stated: --- In the html page that Tomcat returns for the URL /ASAAP, change the relative link to an image, from this : img src=images/bg_hdr_logo.gif width=254 height=132 border=0 to this : img src=/ASAAP/images/bg_hdr_logo.gif width=254 height=132 border=0 My servlet uses templates that are relative to the webapps/context folder. I don't tell the template anything more than this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=115 border=0/td The images are in the webapps/context/images folder and the templates are in the webapps/context/templates folder. Is seems to me that if I change it to pre-append an /ASAAP in front of all of my image references, it will break the application. This structure is working fine in another environment where the context isn't the ROOT context. I think that is where my problem lies although I admit I don't know terribly much about application servers and how they specifically work. Since this servlet deploys correctly in another Apache/Tomcat environment I can only assume it is a configuration issue, not a problem with the application itself. There was a suggestion to use /* for the JKMount entry but that seems like all web requests would be routed to the servlet with that directive and therefore the PHP and other web applications served by Apache would fail. I will keep your recommendation in mind but I think I'll rather change the configuration to one that works rather than have to change the application itself. Pete André Warnier wrote: Pete Helgren wrote: [...] Pete, I really think you should re-read my previous answer. I did a quick check on the page you indicated, using Firefox and it's LiveHttpHeaders add-on, and the result in summary is : The first link to the page, ending in /ASAAP , works fine. But subsequently, the browser is requesting URLs like : GET /stylesheets/value.css HTTP/1.1 GET /images/bg_hdr_logo.gif HTTP/1.1 etc.. and getting consistently 404 Not found responses. And, these responses come from Apache, not Tomcat. And, it is normal because : In the configuration of mod_jk in Apache, either with the JkMount directives or the Location section that you tried, what you are actually saying to the Apache mod_jk module is : 'grab all requests that start with /ASAAP, and send them to Tomcat to generate the content for them; then grab the content back as Tomcat generates it, and return that to the browser. And that's fine and it also works fine for your starting page. But, because of the way the relative links to stylesheets and images are , in the html page that Tomcat returns, the following requests from the browser are for URLs like above, /which do not start with /ASAAP/. Thus, mod_jk could not care less about these, and lets Apache itself generate the content for them. So now Apache is looking in its own DocumentRoot (probably something like /var/www/docs, for an object that matches the path /images/bg_hdr_logo.gif, and it does not find it. So it returns a 404 not found. Apache has no reason at all to go look for these objects in Tomcat's application directory (which is not at /var/www/docs but somewhere else) to go find these objects, and it will not. Why does it work when you access Tomcat directly (on port 8080) ? Because then, your browser is getting the initial page from the Tomcat at http://yourhost:8080/ASAAP;. So when the browser sees, in that page, a relative link like images/bg_hdr_logo.gif, it will issue a new request to http://yourhost:8080/images/bg_hdr_logo.gif; (thus to Tomcat). And, presumably,
Re: AJP13 Connector and JKOptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/19/2009 12:31 PM, Pete Helgren wrote: My servlet uses templates that are relative to the webapps/context folder. I don't tell the template anything more than this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=115 border=0/td You should be telling it something like this (shown in JSP-speak) img src=%= request.getContextPath() %%= response.encodeURL(/images/bg_hdr_logo.gif) % ... Note: 1. The use of request.getContextPath 2. The use of response.encodeURL to add ;jsessionid=... if necessary 3. The leading / on your image's URL This technique will always work, which is why you should always use it. The images are in the webapps/context/images folder and the templates are in the webapps/context/templates folder. Is seems to me that if I change it to pre-append an /ASAAP in front of all of my image references, it will break the application. You're right, because blindly appending /ASAAP to all your URLs means that you can't easily rename the context (or put it in ROOT). Using the dynamic technique above will make it work no matter where you put it. Since this servlet deploys correctly in another Apache/Tomcat environment I can only assume it is a configuration issue, not a problem with the application itself. Successful deployment does not guarantee that the application isn't broken. There was a suggestion to use /* for the JKMount entry but that seems like all web requests would be routed to the servlet with that directive and therefore the PHP and other web applications served by Apache would fail. You want to map this: JkMount /contextName/* worker ... if you just want to be done with it. If you want to use Apache for static content, you'll have to be more gentle with your mappings. Say, something like this: JkMount /contextName/*.jsp worker JkMount /contextName/*/j_security_check worker JkMount /contextName/*.do worker JkMount /contextName/*.action worker JkMount /contextName/*.whatever worker I will keep your recommendation in mind but I think I'll rather change the configuration to one that works rather than have to change the application itself. This problem is likely to plague you wherever you go unless you fix this problem. If it's working when deployed to a context /other/ than ROOT, then don't deploy it to ROOT. The real problem is that you can't alias / to more than one thing at a time. Since /images (to httpd) points to your DocumentRoot (not your webapp's root), it can't find your stuff. The reason it works when you deploy your application to a non-ROOT context is because your JkMount setup forwards /all/ requests to Tomcat for /contextName, and Tomcat knows where the webapp's root is. This is not a configuration problem. This is a misunderstanding of the relationship between httpd and Tomcat, and an oversight in the way you (don't) dynamically generate resource URIs in your web application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmdrMgACgkQ9CaO5/Lv0PA6KwCfRw0KTyUhLd9uxiNF9bBMpt6z W4IAnA0/EO+uT2+DLrm69/6E5Z+vylF6 =wQli -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Chris, Thanks I'll that that to heart and dig deeper into the application structure itself when I get the opportunity. I use Freemarker (and a smaller framework called niggle) as my servlet template engine and the only other thing I reference is a resource base in the servlet context like this: init-param param-nameRESOURCE_BASE/param-name param-value../../templates/param-value /init-param Perhaps niggle is doing the context magic for me but I haven't run into this issue in other deployments, just this one. And, as you indicate, it could be dumb luck (wouldn't be the first time!) I appreciate the help and the good counsel and I'll try on a couple of things for size this evening and let you know how things turn out in the morning Pete Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/19/2009 12:31 PM, Pete Helgren wrote: My servlet uses templates that are relative to the webapps/context folder. I don't tell the template anything more than this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=115 border=0/td You should be telling it something like this (shown in JSP-speak) img src=%= request.getContextPath() %%= response.encodeURL(/images/bg_hdr_logo.gif) % ... Note: 1. The use of request.getContextPath 2. The use of response.encodeURL to add ;jsessionid=... if necessary 3. The leading / on your image's URL This technique will always work, which is why you should always use it. The images are in the webapps/context/images folder and the templates are in the webapps/context/templates folder. Is seems to me that if I change it to pre-append an /ASAAP in front of all of my image references, it will break the application. You're right, because blindly appending /ASAAP to all your URLs means that you can't easily rename the context (or put it in ROOT). Using the dynamic technique above will make it work no matter where you put it. Since this servlet deploys correctly in another Apache/Tomcat environment I can only assume it is a configuration issue, not a problem with the application itself. Successful deployment does not guarantee that the application isn't broken. There was a suggestion to use /* for the JKMount entry but that seems like all web requests would be routed to the servlet with that directive and therefore the PHP and other web applications served by Apache would fail. You want to map this: JkMount /contextName/* worker ... if you just want to be done with it. If you want to use Apache for static content, you'll have to be more gentle with your mappings. Say, something like this: JkMount /contextName/*.jsp worker JkMount /contextName/*/j_security_check worker JkMount /contextName/*.do worker JkMount /contextName/*.action worker JkMount /contextName/*.whatever worker I will keep your recommendation in mind but I think I'll rather change the configuration to one that works rather than have to change the application itself. This problem is likely to plague you wherever you go unless you fix this problem. If it's working when deployed to a context /other/ than ROOT, then don't deploy it to ROOT. The real problem is that you can't alias / to more than one thing at a time. Since /images (to httpd) points to your DocumentRoot (not your webapp's root), it can't find your stuff. The reason it works when you deploy your application to a non-ROOT context is because your JkMount setup forwards /all/ requests to Tomcat for /contextName, and Tomcat knows where the webapp's root is. This is not a configuration problem. This is a misunderstanding of the relationship between httpd and Tomcat, and an oversight in the way you (don't) dynamically generate resource URIs in your web application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmdrMgACgkQ9CaO5/Lv0PA6KwCfRw0KTyUhLd9uxiNF9bBMpt6z W4IAnA0/EO+uT2+DLrm69/6E5Z+vylF6 =wQli -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Pete Helgren wrote: Thanks Andre. And, I DID carefully read your original post and I had some inkling that the problem had to do with context vs the JKMount directive. I had concluded that Apache had difficulty serving the images and I figured that the JKMount reference somehow was in the middle of it. References with /ASAAP were being rendered . Those without /ASAAP weren't rendering. What I am after is what is wrong with the current config in Apache or Tomcat that is breaking the references since another application works fine with that reference structure. In the other example I posted that DOES work, the JKMount is /asaap3/ASAAP and the Tomcat context is asaap3 with servlet url being /asaap3/ASAAP. Not sure why the images in that case *are* being found . Hi again. Considering the last phrase above, and with all due respect, I think you still haven't really got it. Let me try another way. Forget that you have a Tomcat and an Apache, and consider things from the point of view of any browser which accesses a webserver, any webserver. Step 1: you enter the url http://anyhost/ASAAP;, and the browser in return receives a html page. Now, for the browser, http://anyhost/ASAAP; *is* the place it got this page from, and it is his baseline for this page. That is true no matter which aliases, front-ends, back-ends, dynamic of static mechanisms have participated on the server side in producing that page in reality. The browser doesn't know that. It knows only that it asked for http://anyhost/ASAAP;, and it got this page in return. Step 2: in the received page, the browser finds a link to images/myimage.gif. In the absence of any other information, the browser is going to request that item, from the same server, by doing the following : - it removes the last element of the URL (in this case http://anyhost/ASAAP;) from which it received the current page. In this case thus, it removes the ASAAP, leaving http://anyhost/;. - then it adds the relative link to that. So it concatenates http://anyhost/; with images/myimage.gif, giving http://anyhost/images/myimage.gif;. - then it requests that URL Now the above is true for any browser, talking to any server, and there is nothing you can do about it. No amount of server configuration is going to chane the logic above, since it is the inherent logic of a browser. So it will be so as long as : a) either you modify the links in your pages so that they re-introduce this element ASAAP/ that is stripped by the above operation b) or you find a way to make the browser believe that it did not get the first page above from http://anyhost/ASAAP;, but from (for instance) http://anyhost/ASAAP/index.html;. Since (for good reasons, I agree with your reasons) you do not want to modify the references in your pages (a), then you must find a way to do (b). Here is one way : When the browser requests the URL http://anyhost/ASAAP;, it should be told that page does not exist (or has moved), please request http://anyhost/ASAAP/index.jsp; instead. Then the browser will do that, and request http://anyhost/ASAAP/index.jsp;, and receive the original page. Now the browser knows that this page has been received from http://anyhost/ASAAP/index.jsp;. So when it finds a relative link in that page, it is going to follow the same steps as above, but this time what it will remove will be the index.jsp at the end, and what will be left before adding the relative link will be http://anyhost/ASAAP/;. So now it will request http://anyhost/ASAAP/images/myimage.gif; and bingo ! that is what your JkMount says to redirect to Tomcat, and bingo again ! Tomcat knows where that is (hopefully) and can return it.(*) So you need, either at the Apache or at the Tomcat level, to make sure that in case someone requests http://yourhost/ASAAP;, his browser gets a redirect response pointing to http://yourhost/ASAAP/index.jsp; for example. There are probably other possibilities based on a change of your application directory structure and/or mappings in Tomcat. But I cannot help you there, because I don't know what your Tomcat setup really is. Since trying the link http://altusschools.k12.ok.us/ASAAP/; (with a trailing /) returns a /Tomcat/ 404 error, I guess that at this moment you have not mapped the URL /ASAAP/ to your webapp. Maybe you should. Can you give us the exact directory structure below the /webapps/ directory in your Tomcat ? It would help to know where the images and stylesheets really are with relation to the ROOT and ASAAP subdirectories. (*) Note that from the look of it, Tomcat does not know where the URL http://yourhost/ASAAP/images/myimage.gif; is, and that is a problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
Thanks for your patience Andre. I appreciate your careful, step by step description. I tried a couple of things based on your information and a suggestion from Chris. I started by trying JKMount of /* to my worker and it did work, like I expected, but it also broke all the other apps that Apache was serving through PHP, which I expected. Christ suggested that I use JKMount /context/* but not knowing exactly how that would play when the context was ROOT I went ahead and installed the application at the /asaap3 context so the final JKMount entry was /asaap3/* . That works! And I understand why. All of the folders like /templates /scripts /images /stylesheets are off of the context so now the /asaap3/ASAAP pages have the correct url mapping. The anyhost/asaap3/ASAAP returns the correct path to anyhost/asaap3/images/bg_hdr_logo.gif So you can not only find the correct page, but the correct images as well. The slightly longer URL isn't an issue. /asaap3/ASAAP vs /ASAAP isn't a problem. Again, thanks for the patient explanations. Pete André Warnier wrote: Pete Helgren wrote: Thanks Andre. And, I DID carefully read your original post and I had some inkling that the problem had to do with context vs the JKMount directive. I had concluded that Apache had difficulty serving the images and I figured that the JKMount reference somehow was in the middle of it. References with /ASAAP were being rendered . Those without /ASAAP weren't rendering. What I am after is what is wrong with the current config in Apache or Tomcat that is breaking the references since another application works fine with that reference structure. In the other example I posted that DOES work, the JKMount is /asaap3/ASAAP and the Tomcat context is asaap3 with servlet url being /asaap3/ASAAP. Not sure why the images in that case *are* being found . Hi again. Considering the last phrase above, and with all due respect, I think you still haven't really got it. Let me try another way. Forget that you have a Tomcat and an Apache, and consider things from the point of view of any browser which accesses a webserver, any webserver. Step 1: you enter the url http://anyhost/ASAAP;, and the browser in return receives a html page. Now, for the browser, http://anyhost/ASAAP; *is* the place it got this page from, and it is his baseline for this page. That is true no matter which aliases, front-ends, back-ends, dynamic of static mechanisms have participated on the server side in producing that page in reality. The browser doesn't know that. It knows only that it asked for http://anyhost/ASAAP;, and it got this page in return. Step 2: in the received page, the browser finds a link to images/myimage.gif. In the absence of any other information, the browser is going to request that item, from the same server, by doing the following : - it removes the last element of the URL (in this case http://anyhost/ASAAP;) from which it received the current page. In this case thus, it removes the ASAAP, leaving http://anyhost/;. - then it adds the relative link to that. So it concatenates http://anyhost/; with images/myimage.gif, giving http://anyhost/images/myimage.gif;. - then it requests that URL Now the above is true for any browser, talking to any server, and there is nothing you can do about it. No amount of server configuration is going to chane the logic above, since it is the inherent logic of a browser. So it will be so as long as : a) either you modify the links in your pages so that they re-introduce this element ASAAP/ that is stripped by the above operation b) or you find a way to make the browser believe that it did not get the first page above from http://anyhost/ASAAP;, but from (for instance) http://anyhost/ASAAP/index.html;. Since (for good reasons, I agree with your reasons) you do not want to modify the references in your pages (a), then you must find a way to do (b). Here is one way : When the browser requests the URL http://anyhost/ASAAP;, it should be told that page does not exist (or has moved), please request http://anyhost/ASAAP/index.jsp; instead. Then the browser will do that, and request http://anyhost/ASAAP/index.jsp;, and receive the original page. Now the browser knows that this page has been received from http://anyhost/ASAAP/index.jsp;. So when it finds a relative link in that page, it is going to follow the same steps as above, but this time what it will remove will be the index.jsp at the end, and what will be left before adding the relative link will be http://anyhost/ASAAP/;. So now it will request http://anyhost/ASAAP/images/myimage.gif; and bingo ! that is what your JkMount says to redirect to Tomcat, and bingo again ! Tomcat knows where that is (hopefully) and can return it.(*) So you need, either at the Apache or at the Tomcat level, to make sure that in case someone requests http://yourhost/ASAAP;, his browser gets a redirect
Re: AJP13 Connector and JKOptions
On Feb 18, 2009, at 8:17 AM, Pete Helgren wrote: Still struggling with this so I am reposting. I can't seem to find a configuration that allows the images and links to properly display. Info from prior posts: I have a Tomcat application that serves up a web app when I use a URL like this: http://www.mywebsite.com:8080/MyAPP Which I wanted to change to this: http://www.mywebsite.com/MyAPP Using Apache I added the worker.properties file and the following directives to an existing Apache server that has been serving several sites. #Tomcat Settings # Mount the worker containing MyAPP JKMount /MyAPP myappw How about: JkMount /MyApp* myappw ?? János # Globally deny access to the WEB-INF directory LocationMatch '.*WEB-INF.*' AllowOverride None deny from all /LocationMatch The pages display but none of the images display and several of the webapps links are broken. So, something isn't quite right. It is almost as though the application links aren't relative to the correct root. I read through the JKOptions for Apache but can't tell if I need to add one or more options to allow the links to correctly display. The reason for the use of Apache is that there are several web sites currently hosted on this server (PHP and static sites) served by Apache so it seemed logical to use Tomcat with an Apache front end to serve the Java Servlet. Any suggestions would be greatly appreciated. Apache/2.2.11 (Win32) DAV/2 mod_jk/1.2.27 mod_ssl/2.2.11 OpenSSL/ 0.9.8i Tomcat 5.5.27 Anyone seen this before? Any suggestions? - 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: AJP13 Connector and JKOptions
János Löbb wrote: On Feb 18, 2009, at 8:17 AM, Pete Helgren wrote: Still struggling with this so I am reposting. I can't seem to find a configuration that allows the images and links to properly display. Info from prior posts: I have a Tomcat application that serves up a web app when I use a URL like this: http://www.mywebsite.com:8080/MyAPP Which I wanted to change to this: http://www.mywebsite.com/MyAPP Using Apache I added the worker.properties file and the following directives to an existing Apache server that has been serving several sites. #Tomcat Settings # Mount the worker containing MyAPP JKMount /MyAPP myappw How about: JkMount /MyApp* myappw ?? Or use the following at the Apache level : Location /MyApp SetHandler jakarta-servlet /Location See here for details (also on JkMount above) : http://tomcat.apache.org/connectors-doc/reference/apache.html Scroll down to Using SetHandler and Environment Variables - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/18/2009 8:17 AM, Pete Helgren wrote: The pages display but none of the images display and several of the webapps links are broken. So, something isn't quite right. It is almost as though the application links aren't relative to the correct root. What do the URLs look like in the page itself? Like in the img src=... / HTML elements. Is the URL is wrong, it's not going to work. Also, if you are using Apache httpd to serve static content, URLs containing the ;jsessionid=123456789 parameter aren't interpreted correctly by Apache httpd and you should add JkStripSession On to your configuration. This will allow Apache to properly serve static images that include this jsessionid parameter. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmcaT0ACgkQ9CaO5/Lv0PDT5wCfY28zvbYD/BjOb6hMzjKUX81W iFYAoIz62/NzUiYv77lcbZG7FWECgOJ1 =1YWc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions
What do the URL's look like? Here is an example. If I right click and get the properties on the missing image, I see this (well I'd add a more real looking URL but the this mailing list has rejected my last 9 attempts as spam...): MyDomain/images/bg_hdr_logo.gif and the image does NOT display. The actual source from that page view source shows this: td valign=top class=body12img src=images/bg_hdr_logo.gif width=254 height=132 border=0/td So, looking at the page that DOES display correctly I see this for the image properties: localhost:8080/images/bg_hdr_logo.gif It looks like both resolve to the /images folder correctly in the URL but does Apache pass the /images/ url to Tomcat? In this case, the *only* reason I am using Apache as the front end is so that the URL can be friendly. That is, have it run through port 80 and served up with the other web apps that Apache is running. Apache has no other role except to pass through the traffic to Tomcat. Apache will serve no content at all. That is it. The site, run directly to/through Tomcat is *perfect*. No problems with URL, images, anything. I just want to access the app, located on the same hardware and through the same IP as the Apache app like this: MyDomain/MyAPP If there is another way to have Tomcat serve the app at port 80 at the same IP address as Apache, I'd be happy to entertain it. Using AJP seemed the right way to do it. I am going to look into Andre's suggestion to use: Location /MyApp SetHandler jakarta-servlet /Location and see what happens with that option. I'll post back. Pete Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete, On 2/18/2009 8:17 AM, Pete Helgren wrote: The pages display but none of the images display and several of the webapps links are broken. So, something isn't quite right. It is almost as though the application links aren't relative to the correct root. What do the URLs look like in the page itself? Like in the img src=... / HTML elements. Is the URL is wrong, it's not going to work. Also, if you are using Apache httpd to serve static content, URLs containing the ;jsessionid=123456789 parameter aren't interpreted correctly by Apache httpd and you should add JkStripSession On to your configuration. This will allow Apache to properly serve static images that include this jsessionid parameter. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmcaT0ACgkQ9CaO5/Lv0PDT5wCfY28zvbYD/BjOb6hMzjKUX81W iFYAoIz62/NzUiYv77lcbZG7FWECgOJ1 =1YWc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP13 Connector and JKOptions]
Andre, Thanks. This Apache instance is running on Windows Server 2003 and already has several web sites running at port 80. Some static, some PHP. I am a Java guy so a Tomcat servlet was my natural way of writing the app. To my knowledge I can't have more than one web server listening on port 80 on this IP so my solution was to install Tomcat 5.5.27 and use AJP13 to serve the pages back to Tomcat. Is there a better way? The services panel in Windows Server 2003 says this: Apache/2.2.11 (Win32) DAV/2 mod_jk/1.2.27 mod_ssl/2.2.11 OpenSSL/0.9.8i This isn't my server, just my app. Since I can run this successfully on my Windows server 2003, Apache 2.2 and Tomcat 5.5 I figured this would be the easiest way to approach it. I can tell that I am close, I am just missing something subtle. Thanks - Original Message - From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Saturday, February 14, 2009 3:26 AM Subject: Re: AJP13 Connector and JKOptions Pete Helgren wrote: [...] Hi. Maybe start at the beginning and let us know : - which version of Tomcat you are running - on what kind of box (the OS) - with which version of Apache Then, - do you have any reason to be using an Apache front-end, other than wanting to get rid of the :8080 in your URL links ? Because if not, then you do not need an Apache front-end to do that. Just change the port=8080 to port=80 in the HTTP Connector element of your Tomcat's server.xml file, and restart Tomcat. (But stop Apache first, otherwise they will fight for port 80). If you have another reason to configure an Apache, then it is a bit more complicated. But please then provide the requested information first. - 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: AJP13 Connector and JKOptions
Pete Helgren wrote: [...] Hi. Maybe start at the beginning and let us know : - which version of Tomcat you are running - on what kind of box (the OS) - with which version of Apache Then, - do you have any reason to be using an Apache front-end, other than wanting to get rid of the :8080 in your URL links ? Because if not, then you do not need an Apache front-end to do that. Just change the port=8080 to port=80 in the HTTP Connector element of your Tomcat's server.xml file, and restart Tomcat. (But stop Apache first, otherwise they will fight for port 80). If you have another reason to configure an Apache, then it is a bit more complicated. But please then provide the requested information first. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
