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.

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.

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?

Reply via email to