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="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
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, 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org