tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <>
Subject Re: Reversed deployment configuration for mod_webapp...
Date Thu, 18 Oct 2001 10:29:37 GMT
Pier Fumagalli wrote:
> I've been looking in the past month at which were the main difficulties in
> mod_webapp usage, and I think that the most difficult part for users comes
> when someone tries to deploy a web-application both in server.xml and
> httpd.conf. Why? Let's see an example:
> httpd.conf
> ----------
> ServerName myhost.domain.dom
> Port 80
> WebAppConnection conn warp myhost.domain.dom:8008
> WebAppDeploy examples conn /examples
> server.xml
> ----------
> <Connector className="...WarpConnector" ... />
> <Engine className="...WarpEngine">
>   <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true"
>         className="...WarpHost">
>     <Context path="/examples" docBase="examples">
>     </Context>
>   </Host>
> </Engine>
> To the random viewer, this looks like a valid configuration, the context
> deployed in server.xml should be seen under /examples by Apache...
> BUT (yeah, there's always a but), what's going to happen is that when run,
> we're going to have TWO instances of the examples context: one deployed for
> the "localhost" host (configured in server.xml) and one configured for
> "myhost.domain.dom" (configured in httpd.conf and autodeployed by WARP).
> Basically, if you're not careful enough, things are going to be screwed up,
> and you won't get what you want.

- Sure I have tried to help several time in user list about this...

> One possible solution to the problem would be to reverse the deployment
> scheme of WARP. If we put all context configurations in server.xml, and add
> a directive such as "WebAppDeployAll true", what we can achieve is that for
> a particular <VirtualHost...> or root the root server configured in
> httpd.conf, we're going to automatically retrieve all contexts configured in
> server.xml for that particular host.

Like "JkAutoMount * myworker1 *" (in a <VirtualHost.../>).

> This will solve a bunch of problems, but there is one tiny little bit that
> is still lacking from Catalina, and that makes things hard: apache, and all
> other webservers, use the "Host" header to select what named virtual host
> I'm using. The "Host" header, though, is formatted in this way: "host:port".
> So, what it basically means is that a virtual host name is made up by two
> values: the name and the port. Catalina standalone works great, because I
> can just set up two connectors in two engines, with two different ports, and
> have different behaviours for two virtual hosts having the same name but
> different port values.
> When coming down to WARP, we have one single connector getting all requests
> thru one single port, so, what we need to do is use a selector also over on
> a port to figure out the "real" virtualhost (host:port) to use.

What about using host_port (or any character is not valid in hostname)?
When I try to add server localhost_8080 J2EE gives a funny error message "Cannot
connect to host".

> I'm planning to implement this mapping in the Warp* classes (not to break
> anything back), basically rewriting the map methods and adding a
> setPort/getPort property into host. But by doing this I won't be able to use
> the Standard* implementation of the Catalina stuff... My only problem is how
> this could cope with the Manager Application.

Specialy how to detect that sometime has changed?

>     Pier

View raw message