dev@glassfish.java.net

Re: HEADS-UP: default-web-module optimization

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Thu, 31 Aug 2006 14:48:16 -0700

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