Reversed deployment configuration for mod_webapp...

[Pier Fumagalli <pi...@betaversion.org>]

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.

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.

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.

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.

    Pier

Re: Reversed deployment configuration for mod_webapp...

[Pier Fumagalli <pi...@betaversion.org>]

jean-frederic clere at jfrederic.clere@fujitsu-siemens.com wrote:

>> 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...

You know what I mean :)

>> 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.../>).

Kinda... The only thing is that all available applications are passed over
the wire...

>> 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".

Because it would be a hack :) I am still hesitant on this... Maybe removing
WarpHost is the right solution, but despite all my questions, noone seems to
care...

>> 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?

That's easy... The connector can be notified using events, when an
application is added (for example) then all you do is close the warp socket,
and when apache reopens it, you can simply call the reconfiguration...

    Pier

Re: Reversed deployment configuration for mod_webapp...

[jean-frederic clere <jf...@fujitsu-siemens.com>]

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