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