tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Helgren <>
Subject Re: AJP13 Connector and JKOptions
Date Thu, 19 Feb 2009 17:31:13 GMT
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" 

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="body12"><img 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 

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.


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, 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message