Bill Shannon wrote On 08/31/06 00:13,:
> Jan Luehe wrote:
>
>> By declaring a web module as a default-web-module, you "promote" it
>> and give it higher visibility: You can access it without even knowing
>> its name, just by accessing "/", which, when you access the GlassFish
>> admin port, will give you the "admingui". But you could also access the
>> admingui via its configured context root "/asadmin".
>>
>> You can change a virtual server's default-web-module as you please
>> (and your updates will take effect immediately). When you do that, you
>> can select among any of the web modules already deployed on the
>> virtual server. Say you've deployed web module "123" at "/123", and
>> you now want to make it the virtual server's default-web-module. The
>> web module will now be available at "/", in addition to "/123" (removing
>> it from "/123" would have required an undeploy).
>>
>> The semantics of default-web-module, as described above, have been
>> around
>> for a long time (I believe since iAS7), which is why we need to
>> preserve them.
>
>
> I understand *what* happens. What I don't understand is why we thought
> that was a good way to make it work? What's the motivation for having
> a single web app be deployed both at a normal context root and at "/"?
>
> Rather than deploying a web app normally and then "promoting" it, why
> not simply deploy it at "/" to begin with?
>
> Are we doing this just to remain compatible with Tomcat? (Which begs the
> question, why did Tomcat do it this way to begin with?)
Tomcat is not an issue here. We need to stay backwards compatible with
earlier AS versions.
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 "/".
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".
Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>