RE: Configuring contexts and using separate web servers / connect ors

[Colin Wilson-Salt <co...@london.virgin.net>]

I guess my belief then, is that as a web application requires a context
path, there should be no requirement that the context path that it is
deployed under in Tomcat should match the URL-prefix that it is served from
by the web server.

This would mean that it would be more sensible to sort this out in the web
server, by adding a separate parameter that says where the application is
served from:

WebAppDeploy classbrowser conn /classbrowser
/deep/within/my/site/classbrowser

Still, I can see your point, that if a servlet does
request.getContextPath(), it needs to get something that it can sensibly
use, and perhaps I should just accept that this is the way things are.

It does seem a shame though that I can't, for instance, have an application
deployed in one tomcat instance, but with two webservers serving the
application under different URL prefixes.

For instance:

http://www.mycompany.com/deep/within/my/site/classbrowser/

and

http://classbrowser.mycompany.com/

Thanks for listening, anyhow.

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, September 03, 2001 19:21
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Configuring contexts and using separate web servers /
> connectors
> 
> 
> Hi Colin,
> 
> Thanks for the contribution!  See below for some comments on your
> suggestions.
> 
> On Mon, 3 Sep 2001, Colin Wilson-Salt wrote:
> 
> > Date: Mon, 3 Sep 2001 10:06:59 +0100
> > From: Colin Wilson-Salt <co...@london.virgin.net>
> > Reply-To: tomcat-dev@jakarta.apache.org
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Configuring contexts and using separate web 
> servers / connectors
> >
> > I hope some of you will bear with me through this email as 
> I share my
> > thoughts and try to be persuasive.
> >
> > In a live environment, I probably would not have any HTTP 
> connector enabled
> > in Tomcat, instead Apache or iPlanet would listen to HTTP 
> and talk a fast,
> > efficient and proprietary protocol to Tomcat for any web-application
> > requests.
> >
> > Let's say that I have an application deployed in Tomcat. 
> Let's call it
> > "classbrowser". I can deploy it with a line in server.xml like:
> >
> > <Context path="/urlprefix"
> >          docBase="/home/colin/work/classbrowser.war"/>
> >
> > I can then point my browser to 
> http://localhost:8080/urlprefix/ and get
> > pages back from my application. Woohoo.
> >
> > Now I go to configure my webserver (in this case iPlanet 
> with a plugin based
> > on the mod_webapp stuff). I give it this configuration:
> >
> > WebAppConnection conn warp localhost:8008
> > WebAppDeploy classbrowser conn /classbrowser
> >
> > Which means deploy an application, named "classbrowser" to 
> appear below the
> > URL /classbrowser on the port that my iPlanet is listening 
> to. So I should
> > be able to point my browser to 
http://localhost:81/classbrowser/ and have
> stuff work.
>
> However, although the iPlanet / mod_webapp stuff knows that that means an
> application named "classbrowser" that needs to be delegated to Tomcat,
> Tomcat doesn't know what I'm talking about.
>

In the Apache-connected case, you need to have the appropriate <Context>
entry in your server.xml file (or let Tomcat auto-configure the context if
it's in the "webapps" directory).  Wouldn't the same thing work here?

> I need to be able to give an application a name when I deploy it to
Tomcat,
> and have that name and the name used to configure the mod_webapp stuff
used
> to connect the two halves together.
>

The context path ("/classbrowser") can do that for you.

> In the case where Tomcat is not doing HTTP itself, the path attribute in
the
> Context entry is irrelevant, and should be able to be replaced with a name
> attribute. This name attribute, plus any extra path information after the
> url-prefix used to match requests on the web server side, should be what
> gets sent to Tomcat.
>
> The above example would then become:
>
> <Context name="classbrowser"
>          docBase="/home/colin/work/classbrowser.war"/>
>
> Is this something that people generally agree with?
>

The servlet API requires that a web application have a context path
(visible to the application via request.getContextPath()).  So, Tomcat
would have to create such a context path based on this entry, and it's not
clear how you would define the rules.  If it's something simple like "add
a slash at the beginning", it seems to me that this entry is equivalent:

  <Context path="/classbrowser"
           docBase="/home/colin/work/classbrowser.war"/>

and the "path" attribute serves two purposes:
* It provides the context path to which this app will be attached
* It provides a unique identifier that can be used by a web connector
  to select this application.

I guess I'm not understanding why this might not be sufficient.

Craig