Craig McClanahan wrote:
> Ken Paulsen wrote:
>> 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.
> I have no idea what *you* mean by "real", but the app that Tomcat maps
> to this context path is 100% as functional as any other webapp
> deployed to Tomcat. It can do, for example, what Bill describes ...
> *be* the admin app on the 4848 port, without having to redirect to a
> different app on the same virtual host. Glassfhish cannot do that --
> if it can, then we are currently making the world needlessly complex
> for users.
>
>>> 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.
>>
> Then what is the point of the "default app" setting? Seems like
> totally useless noise that implements confusingly redundan t access to
> the same functionality. Sounds like a waste of time (for us) to
> implement and (for users) to understand.
I think its a matter of preference. I like the flexibility to still
have a meaningful context-root, and still be able to allow users of the
app to visit a simple url. As Jan pointed out, you can also switch
"default apps" w/o any need for redeployment... while in practice this
is not likely to be used often (perhaps only during my
re-write-of-an-app scenario; or a hosting domain that rotates promoted
apps -- this is a stretch), it demonstrates the power of an "alias" vs.
a dedicated app deployed at "". Since this isn't a feature that the
user has to know about, but is there if they seek it out... I think it's
worth leaving. But that's just my 2 cents. I respect your view that
adding any additional possible configurations only adds possible
confusion. I could live w/o this feature.
Ken
>> Ken
>
> Craig
>
>
>>>
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>