WillF wrote:
What are some best practices surrounding explicitly specifying context path?
E.g. naming the war file like the context path, replacing '/' by '#'. Or
using a context descriptor (the xml file that's called context.xml
inside your webapp/META-INF resp. my#webapp#something.xml inside
CATALINA_BASE/conf/<ENGINE>/<HOST>.
I remember reading somewhere that said it is ignored and should not be used?
Is there any truth to this?
No, you shouldn't define things like that in server.xml, and it's best
to simply name the war file correctly.
Instead of mod_jk do you think mod_proxy would make things easier for
something like this?
Easier for changing the request URLs and fixing Redirect and Cookie
paths. Not easier with respect to wrong links in request pages themselves.
Regards,
Rainer
Rainer Jung-3 wrote:
WillF wrote:
I am currently using mod_jk as the connector and I have Apache as a front
for
tomcat5 by adding something like
JkMount /helloworld/* ajp13 to the httpd.conf
So when I go to www.domain.com/helloworld/
it forwards the request to tomcat and looks for the webapp who's context
path is helloworld. This is all fine and good
but what if i wanted something like
www.domain.com/test/helloworld
and i use JkMount /test/helloworld/* ajp13
how do i create the mapping then? Does it try to look for an app context
path of /test/helloworld?? In tomcat can you even have an web application
with that sort of path?
Yes and yes.
For multi-level context paths see e.g.
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
and look out for the character "#".
Currently I have my Host container in server.xml set to www.domain.com, i
even tried to www.domain.com/test/ but i dont think that did anything.
If you want to have a direct context path on the front end Apache then
on the backend Tomcat, you can rewrite Requests and Location headers
(Redirect) with mod_rewrite, but that's a little tedious and can be
easily broken by the webapp (which can then be fixed with even ,more
work with mod_substitute). Think twice, if you really need different
context paths on the frontend and on the backend.
For the request rewriting and redirect/cookie manipulation, mod_proxy
might be in better shape then mod_jk (which has other strengths but not
especially this area), for the correction of wrong links embedded in
content, you might want to look ak mod_substitute, mod_sed or
mod_proxy_html (note: mod_proxy_html != mod_proxy_http).
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
