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