Re: Warp and Webapp

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

John Carnahan at carnahan@protos.lifesci.ucla.edu wrote:

>> I was actually thinking about "reversing" the problem... Instead of
>> configuring it from httpd.conf with "WebAppDeploy....", configuring all in
>> server.xml, and then using in httpd.conf something like "WebAppDeployAll
>> true", in this case, we can also solve the problem of using the Manager
>> application to deploy web applications "live"...
> 
> This is a bad idea (as I describe further below). The problem with this is
> then you need to synchronize the host info in both httpd.conf and server.xml
> since WebAppDeployAll would have to be virtual-host-specific. It could lead to
> a nightmare in the config if each virtual host had to be defined in both
> places. The alternative to this synchronization is to have a more elaborate
> naming scheme for referencing into server.xml. Unfortunately the spec does not
> give us much latitude for this without using Host definitions.

Correct. But in cases when you want to specify something particular inside
your <Context> tag within server.xml, that's absolutely required. I don't
want to backport all Catalina configuration into the httpd.conf...

>> Actually, the application "name" can be used as a full path... For example:
>> 
>> WebAppDeploy /myApplications/shoppingcart.war connection /shoppingcart
> 
> Does it only recognize war files? If so I do not find that very useful. My
> point for doing all of this is setting up an appropriate multi-developer
> environment using Apache VirtualHosts. Using WAR files instead of simple
> directories is not very appealing for development.

Nope... It should also recognize directories... But Pier is a dork and
there's a bug in the path recognition algorithm (it doesn't look if a path
is absolute, it always considers it relative).
It'll be fixed in tomorrow's daily snapshot...

>> As I said, my previous example should work, and rather than adding more
>> configuration stuff in httpd.conf, I'd rather backport what is in server.xml
>> and make apache "see it" right...
> 
> The problem with this, as I already mentioned, is that the virtual hosts
> should be defined in the apache config. The notion of an app-base belongs in
> the description of the virtual host but the tomcat-apache specfic config (WARP
> connector) in server.xml does not (and should not) have any notion of a host.
> The tomcat-standalone does have separate virtual hosts with their own
> corresponding app-base. The better way around this problem is to give tomcat a
> notion of the app-base from each separate virtual host in the apache
> httpd.conf. This way virtual hosts can each have their own base. Adding
> backports to server.xml would only replicate virtual hosts definitions in both
> httpd.conf and server.xml which could lead to synchronization problems. One
> way around this is to support full path info in each WebAppDeploy directive as
> you mentioned above. Another way is to define an app-base for that virtual
> host and then all of the Deploy directives could be relative to that. This way
> it would be more similar to the tomcat-standalone config in server.xml but
> without adding duplicate host definitions.

I completely agree with you on this topic, in fact, the very first
implementation of WARP didn't have ANY concept of Host on the Java side. If
you see it from the protocol, when a WARP request comes in, the request
already carries the ID of the application, and that is mapped to the context
instance. Look at the map() method in WarpHost (the one deciding which
context instance I need to use):

    public Container map(Request request, boolean update) {
        Context context=null;
        this.log("Mapping request for Host");
        if (request instanceof WarpRequest)
            context=((WarpRequest)request).getContext();
        else
            context=(Context)super.map(request,update);

        return(context);
    }

Read it, and you'll see that the WarpRequest already KNOWS what context I
should use for my request... But there is a slight problem, the Manager
application. Without a concept of Host, the Manager application fails to
deploy applications (not that I give much crap about it, but someone might).
I would like to hear what Craig thinks about it...

The best solution would be to have something like:

server.xml
----------
<Server>
  <Service name="Tomcat-Apache">
    <Connector className="org.apache.catalina.connector.warp.WarpConnector"
     port="8008" minProcessors="5" maxProcessors="75"
     enableLookups="true"
     acceptCount="10" debug="0"/>

    <Engine className="org.apache.catalina.connector.warp.WarpEngine"
     name="Apache" debug="0" appBase="webapps">

      <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="apache_log." suffix=".txt"
              timestamp="true"/>

      <Context name="examples" path="/examples" docBase="examples"
               className="org.apache.catalina.connector.warp.WarpContext">
          .... All your context stuff...
      </Context>
    </Engine>
  </Service>
</Server>

httpd.conf
----------
...
<VirtualHost a.host>
    ...
    WebAppUse    examples connection
    WebAppDeploy examples connection /examples2/
</VirtualHost>

<VirtualHost b.host>
    ...
    WebAppUse    examples connection
    WebAppDeploy examples connection /examples2/
</VirtualHost>


What's the difference out here? Is that basically the WarpEngine doesn't
have any concept of host (which resides at the WebServer level), but is just
a collection of Context instances...

Let's see how that configuration WOULD behave:

http://a.host:80/examples
  Gets redirected to the instance of the "examples" application deployed in
  server.xml, so, no fuzz, that's what I get
http://a.host:80/examples2
  A new instance of the same web-application (examples) is deployed for
  another context path: sessions created in a.host:80/examples are NOT VALID
  in a.host:80/examples2
http://b.host:80/examples
  Gets redirected to the SAME INSTANCE we're using for a.host:80/examples,
  so sessions created there are valid also here (note that WebAppUse doesn't
  allow you to specify a path since the servlet specification forbids you to
  deploy the same context instance on two different paths)
http://b.host:80/examples2
  This deploys a third instance of the same web application, but visible
  only from this url...

Reversing the look:

Context #1 can be accessed from:
  http://a.host:80/examples
  http://b.host:80/examples

Context #2 can be accessed from:
  http://a.host:80/examples2

Context #3 can be accessed from:
  http://a.host:80/examples2

That was my original idea.. I would like to see what others think about it
(BTW, John, it's better to move this discussion over on tomcat-dev)...

    Pier