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