Hi Hassan
Maurice here.
Yeah, I've been following this thread, and at this moment
I'm stepping into this discussion because:
My tomcat has four host elements: the primary (localhost -> tomcat/webapps)
as usual, plus three development hosts:
devel.mydomain.net -> tomcat/webappsDevel
devel2.mydomain.net -> tomcat/webappsDevel2
devel3.mydomain.net -> tomcat/webappsDevel3
where, for example, the host is configured:
<Host name="devel.mydomain.net" debug="0" appBase="webappsDevel"...
etc.
And, fronting with Apache 2.0, and using mod_proxy, I just had one heck
of a time getting this to work right. I used httpd <VirtualHost...
sections
but there was a heck of a lot of configuration to do.
In other words, the virtual host of apache will ProxyPass and
ProxyPassReverse
to the appropriate tomcat Host element, where the port number has to appear
(8080,8443) to distinguish from the main (80,443).
There also had to be separate virtual hosts in the ssl.conf in httpd to
handle the
443 -> 8443 side, these also with ProxyPass and ProxyPassReverse.
Seems to me this turned out to be anything but obvious. In addition, if
I don't
want the :8080 and :8443 showing up on the client side URL line in browser,
then I had two solutions that worked:
1) mod_proxy_html to filter these out, which had a simple but non-obvious
configuration, and which turned out to be somewhat expensive, since I
have explicit alsolute URLs inside javascript function argument lists.
(These are formed on the fly from request obj info methods, so they
really start as relative paths, for portability)
The expensive part is that turning on the mod_proxy_html
" ProxyHTMLExtended On" (for parsing script elements on the
outgoing
html) is warned by Nick Kew to be expensive, and it is !
2). (Instead) I actually filter inside the JSP's all the relevant
formed URLs before they
are explicitly written into the javascript args to remove the
:8080 and :8443
in the generated pages. Of course, scheme is indicated by http:
or https:
Bottom line: easy to front tomcat with apache if the tomcat
configuration is
itself simple (only http://www.domain.net, say) but the moment that
additional
tomcat hosts show up, with http/https portions, then this all becomes
much more difficult.
The one difficulty I have NOT seen is losing the session ID.
I do get session ID persistence where it is permitted (across http page
transitions, across https page transitions, and across http->https page
transition)
Maurice Yarrow
Hassan Schroeder wrote:
On 9/25/06, Darren Hall <[EMAIL PROTECTED]> wrote:
....... The client does not want to see urls with an identifier on
the end
of them (i.e. www.abcdomain.com/abc), yet I need the identifier to
correctly
send the request to the correct container in Tomcat (meaning the abc app
lives under the /abc folder under webapps in Tomcat). So when a request
comes in for www.abcdomain.com I need to forward that request to
Tomcat with
an /abc on the end of it so that Tomcat correctly resolves it to the
"abc"
application and then when the response is returned to the user the
url still
appears as www.abcdomain.com with no /abc identifier after it. (Does
this
make sense?
No. Why don't you just have virtual hosts in Tomcat? That would seem
the obvious way to handle this, whether you "need" Apache in front of
it (for some other unrelated reason) or not.
FWIW!
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
