Ken Paulsen wrote On 09/04/06 14:59,:
>
>
> Craig McClanahan wrote:
>
>> Ken Paulsen wrote:
>>
>>>
>>> FWIW, I do think the default-web-module feature is nice. I don't
>>> have the strong use case that Bill is looking for, but it is
>>> convenient. We're in the process of developing the new version of
>>> the GlassFish admin console (JSF-based), and we're doing this as a
>>> new web module. It's nice to deploy them as 2 different context
>>> roots and be able to point the "default" to the old one... for now.
>>> When we're fully functional, we'll just switch the
>>> default-web-module to the new one. As a developer, I can do this
>>> during development. Of course, I can also modify the URL...
>>>
>>> I also like the idea of having a "real" context root, but having my
>>> app easiliy accessible (i.e.: http://localhost:4848). This isn't
>>> possible w/o redirection on server's like Tomcat.
>>>
>> With one minor correction, this *is* actually possible in Tomcat. If
>> you go to URL
>>
>> http://localhost:4848/
>>
>> you will be executing the welcome page of the application that has
>> been installed for context path "" in the Tomcat configuration. No
>> redirection is required.
>
> However, this app has a context-root of "", not something else (which
> is what I meant be "real" context-root). So this limits the set of
> apps that can handle this URL to 1 app deployed as "", and you cannot
> have a "real" context-root for that app w/o redirection.
>
>> It seems that Glassfish actually has a limitation here with respect
>> to Tomcat -- you must deploy your application on a non-default
>> context path, AND point your default context root at it, in order to
>> use a URL like this. That's an extra configuration step, and exposes
>> a public URL in addition to what you really want.
>
> Actually that's not the case. You can deploy an app w/ "" or "/" as
> long as you are not ALSO using the "default-web-module" property (as
> they would obviously conflict). I have tested deploying as "" instead
> of the using the default-web-module property and it works just fine.
Right. Remember default-web-module is an optional virtual-server attribute.
In its absence:
- If the virtual server specifies a docroot, the dummy web module built
off of it becomes the virtual server's default web module, preventing
any other web modules from occupying "".
- Otherwise, the first web module deployed at "" becomes the virtual
server's
default web module.
Jan
>
> Ken
>
>>
>> Craig
>>
>>> If this feature isn't difficult to support, I think it's a good
>>> value-add feature that we have over servers like Tomcat.
>>>
>>> Ken
>>>
>>> Bill Shannon wrote:
>>>
>>>>> 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.
>>>>
>>>>
>>>> That's fine. Thanks for explaining this all to me.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>