dev@glassfish.java.net

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

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Fri, 01 Sep 2006 16:24:20 -0700

Bill Shannon wrote On 09/01/06 15:19,:

> Jan Luehe wrote:
>
>> 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 "".
>
> ...
>
>> 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.
>
>
> Nor does it say that it will. And I still haven't heard a motivation
> for why it should be.
>
>> 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.
>
>
> I'm not sure the way we represent this in domain.xml should drive the
> view of this that we present to users. I think we should consider
> moving to a model more similar to what Tomcat uses, where the default
> web app is the web app that's deployed at "/" (or "" if you prefer).
> Or rather, that designating a web app as the default web app changes
> it to be deployed at "/".


I think domain.xml should always reflect accurately what's deployed
where.

In any case, if we want to follow the Tomcat model, we should just get
rid of the default-web-module attribute in domain.xml, and declare
that a web module is considered a virtual server's default web module
by virtue of being deployed at "/". I agree that would simplify things.
But let's not target this for v2.


Jan

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>