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