Bill Shannon wrote On 08/31/06 14:48,:
> Jan Luehe wrote:
>
>> Tomcat is not an issue here. We need to stay backwards compatible with
>> earlier AS versions.
>
>
> But does Tomcat do it this way or not?
>
>> I believe one of the motivations for the existing behaviour is that it
>> simplifies updating a virtual server's default-web-module without
>> causing any disruption.
>>
>> For instance, assume modules "mod1" and "mod2" deployed on "server",
>> with "mod1" being declared as "server"'s default-web-module. Now if
>> "mod1" was deployed just at "/", and you changed default-web-module to
>> "web2" down the road, you'd have to undeploy both "web1" and "web2",
>> and redeploy "web1" at "/web1" and redeploy "web2" and "/".
>
>
> I still don't understand why you would want to take an existing web
> app and suddenly have it appear as the default web app as well.
>
> It seemed to me that the default web app was good for two, maybe three,
> things:
>
> - As a fallback for any requests that didn't match any other web app.
> - As the only web app in the case where the server is running just one
> web app.
> - As the "root" or primary web app, with other web apps underneath it.
>
> I still don't understand why you would want to present the user a view
> of the default web app, and the same web app running at a different
> context root under itself.
>
>> With our existing impl, with "web1" being the default-web-module, we
>> would have deployed "web1" at "/web1", and a *copy* of it at "/". When
>> updating default-web-module to "web2", "web1" at "/web1" remains intact,
>> but its *copy* at "/" is undeployed, and a *copy* of "web2" is
>> deployed to
>> "/".
>>
>> The proposed optimization will also optimize this scenario, as it
>> will not require *any* redeployments: It will just update the internal
>> mapper to start mapping request for "/" to "web2".
>
>
> Again, assuming that you don't *really* want the same app deployed twice,
> I don't understand why this isn't just a redploy, or maybe an atomic
> "undeploy whatever is at / and deploy this new app at /".
>
> I suppose I could also understand a need for a "move this web app from
> context root /web1 to context root /" operation.
>
>
> I'm still expecting you to tell me that we do it this crazy way because
> that's the way Tomcat does it and even if it doesn't make any sense we
> have to keep doing it that way because that's what users expect... :-)
The way you declare a default context in Tomcat is different from
AS. Tomcat does not support promoting an already deployed web module
to a default web module.
In Tomcat, a web module is considered a default web module by virtue
of its context root, which must be equal to "".
From the Tomcat docs:
You may define as many Context elements as you wish. Each such Context
MUST have a unique context path, which is defined by the path
attribute. In addition, you MUST define a Context with a context path
equal to a zero-length string. This Context becomes the default web
application for this virtual host, and is used to process all requests
that do not match any other Context's context path.
In AS, *any* web module may be promoted to a default web module, by
referencing its id from the virtual server's default-web-module
attribute (no such attribute exists in Tomcat!). In fact, deployment
of a web module with an empty context root will fail in AS, if the target
virtual server declares a default-web-module.
The semantics of default-web-module have existed since iAS7.
Here's a quote from the iAS7 dev guide
(
http://docs.sun.com/source/817-2149-10/dwwebapp.html#wp38547):
Using the Administration Interface
You can assign a virtual server to a web module during deployment as
described in "Deploying Web Applications". To use the Administration
interface to specify a virtual server's default web module:
1. Deploy the web application or J2EE application as described in
"Deploying Web Applications".
2. Open the HTTP Server component under your server instance.
3. Open the Virtual Servers component under the HTTP Server component.
4. Select the virtual server to which you want to assign the web
application.
5. Select the web application from the Default Web Module drop-down list.
6. Select the Save button.
7. Go to the server instance page and select the Apply Changes button.
This doesn't say that the web module you've selected form the drop down
will no longer be available under its original context root.
When you designate a web module as a default-web-module, all that's changing
is the value of the virtual server's default-web-module. The web module
declaration in domain.xml, including its context root, are not changing,
implying that the web module will continue to be available under its
declared context root.
Jan