I did not find the actual problem but I can live with this script not
delivered by apache. Maybe this is because the js is inside a jar file?
Another strange thing is the JkAutoAlias. It realy only works with the
appended ROOT directory. Otherwise the JkUnMount rule matches but apache
cannot find the according file. As long as I do only have one
application this is also OK for me.
Now a third problem occured. I moved the JkMount/JkUnMount part out of
the virtual host into the global config. The mod_jk.conf is loaded
before any other file in conf.d (where ssl.conf resides). As far as I
know every virtual host should now uses this configuration but the one
for port 443 does not!? I have to put the same lines of the global
config into the virtual host for port 443. I am not sure but this also
might be a configuration problem of apache instead of mod_jk.
I did not check the SetHandler part yet but shouldn't it also work with
the JkMount's?
Markus
Am 13.05.2010 14:05, schrieb André Warnier:
Markus Mehrwald wrote:
Hi,
I installed mod_jk and it works perfect except of a little strange
problem. I let handle tomcat everything except of static files which
the following lines in the virtual host for port 80 and the same for
port 443:
# Send servlet for context / jsp-examples to worker named worker1
JkMount /* worker1
# Static files in Tomcat webapp context directory are served by apache
JkAutoAlias /opt/tomcat/webapps/ROOT
JkUnMount /*.jpg worker1
JkUnMount /*.gif worker1
JkUnMount /*.png worker1
JkUnMount /*.js worker1
JkUnMount /*.css worker1
This works great for port 80 but for port 443 the javascript for the
myfaces popup component gets a http 404
(/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12737082/popup.HtmlPopupRenderer/JSPopup.js).
Every other javascript can be retrieved on port 80 as well as on port
443.
Can anyone explain how this can happen?
Maybe.
First, about tracing the error :
- if you bump up the JkLogLevel to "debug", you will get a lot of
information about how mod_jk really tries to match the URL with one of
the URLs it /should/ forward to Tomcat. That may already give you a clue.
- if you use a plugin in the web browser such as HttpFox or
LiveHttpHeaders (for Firefox) or Fiddler2 (for IE), you will get more
information, from the browser point of view, about what happens.
In this case, is the 404 error returned one from Apache, or from Tomcat
? (they have a quite different style, so you should be able to tell).
If it is from Apache, it means that the JkUnMount works, but that Apache
then does not find that file at the indicated path, relative to Apache's
DocumentRoot.
It it is from Tomcat, then it means that mod_jk did not think that it
matched the JkUnMount, and forwarded it to Tomcat (and Tomcat did not
find the .js file).
Considering the above, I have to guess that for some reason, the URL
/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12737082/popup.HtmlPopupRenderer/JSPopup.js
does not match the
> JkUnMount /*.js worker1
which causes Apache to try to serve it, and fail.
The JkMount/JkUnMount syntax is one possible way to do this kind of
thing. But there is another way in Apache, which personally I prefer,
because it "fits better" with the normal Apache configuration style.
Technically, it is equivalent. For your case above it would go as follows :
- remove or comment out all JkMount/JkUnMount directives
- add this :
<Location />
SetHandler jakarta-servlet
SetEnvIf REQUEST_URI "\.(js|jpg|gif|png|css)$" no-jk
...
</Location>
The way it works :
SetHandler jakarta-servlet : tells Apache that for all these URLs
(matching the <Location>), mod_jk is the "handler" which should return
the response.
SetEnvIf : matches the request URI with the given regexp, and if it
matches, sets the internal Apache variable "no-jk" to a non-null value.
Then, when mod_jk gets the request to examine, but it sees that that the
"no-jk" variable is set, and returns to Apache "declined", which
essentially tells Apache "no, this was not for me, do it yourself".
---------------------------------------------------------------------
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
