Ken Paulsen wrote On 09/05/06 08:02,:
>
>
> 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.
As I mentioned in an earlier email, the default-web-module is something that
was introduced in iAS7, way before our time. We need to support it for
backwards compatibility reasons.
The purpose of the original HEADS-UP email has been to make everybody
aware of an optimization in the way support for this attribute has been
implemented:
Rather than treating a default-web-module and its "backing" web module as
two separate web modules (with all the added overhead, such as context
initialization costs), the web module that is referenced by the
default-web-module
attribute now handles requests for both "" and its declared context root,
avoiding the need for creating an extra copy of the web module.
SJSAS/GlassFish supports the same default web module semantics of Tomcat,
with the addition of a default-web-module attribute for greater flexibility.
Whether or not this added functionality is considered useful or not belongs
on a different thread.
Jan
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>