Kyle wrote:
But I have not yet managed to get
www.host.domain.com/<prefix>-examples/<this_or_that_example> to work
without returning a 500 Error.
First is it apache or tomcat that is returning the 500 ?
I'll leave the 500 question till I can be certain of the answer. I
thought it could only be Apache. Will however ensure now.
Then breaking the ServerName and ServerAlias configuration in apache
(restarting apache inbetween)
Not certain I understand what you mean here. Break them ... ?? Do you
simply mean give the default VHost a diff. name to the general
ServerName directive above?
I mean when you are stuck and don't know. Somethings are easier to
deliberatly break the configuration and observe the result (i.e. where
the error shows up now). Since you are trying to work out if the 500
is being produced directly from Apache or is a response apache is just
relaying that really came from Tomcat. It smells like apache to me, but
until you can prove it you wont really know.
You need to confirm that requests for the vhost are being correctly
routed into the VirtualHost section of the apache config. If they are
not then there is no sense looking at the JkMount configuration yet. So
if you have logging setup in apache both in the global config
/usr/local/apache/log/access_log and in the <VirtualHost ...> section to
/tmp/foobar/someother/file/access_log then depending upon which file the
request gets logged will confirm to you that Apache is correctly
configured and working for vhost operation and the <VirtualHost ...>
section your JkMount's are in it indeed coming into play.
JkMount /admin/* ajp13Wkr
This will pass-thru apache everything for the webapp to TC.
I would revise your JkMount to look like:
The multiple jkMount Directives are auto-generated by Tomcat. I could
revise. I just thought it best to just leave them. I suspect they are
so that IF I were to put any static content in those directories,
Apache would pick it up instead.
Yes. But in the situation you are in, setting up "/admin/*" should make
Apache bounce the request off Tomcat if it was not table to serve the
content itself. I am not at all sure what the order of preceedence is
with mixing "Alias", "JkMount" or if the file itself it found in the
document root.
Once you have that established you can then work on your JkMount
settings and Tomcat. Have you checked out, understood and implement
the information in
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/host.html#Host+Name+Aliases
?
Interesting question. Read it, I have.
It is not however clear to me as to whether or not TC _MUST_ have a
_Different_ "VirtualHost Name" than the default VHost name in Apache
or whether it should be the same. And then whether or not an Alias can
or cannot be the same as some other name for that same machine.
Does this mean effectively there should be 3 different names for the
same machine to function in this manner? I.e.
The "ServerName" directive in httpd.conf
The "ServerName" for the default VHost AND
yet ANother different defaultHost/Host name for Tomcat
Different No. The idea is that you can service some content via Apache
directly (maybe this is also PHP or Perl) and other content via
Apache+Tomcat. Apache is always in control, if the request is not
forwarded to Tomcat then you will see the usual Apache like responses (404).
So if you want to a single hostname in the URL then you need to
configure both Apache (ServerName/ServerAlias) and Tomcat (<Host> /
<Alias>) to responsd to the same hostname.
I suspect your only remaining problem now is to get Apache and Tomcat
to see the same website document roots for the same URLs. This maybe
a problem if you are using deployed WARs since tomcat can and will
delete the directory from under apache during the deployment process.
So far, I am only trying to view the examples and default admin app.s
that come bundled with TC. If I understand you correctly here, you are
effectively saying that the auto-conf file generated by TC is not up
to the job and I should dump it in favour of manual inline config.
No... I'm not saying that I have no idea your Apache configuration was
auto-generated by TC. I'm just offering you a methodoligy to observe
some change in behaviour so you can work through the problem yourself.
--
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
