Hi, Jeanfrancois
>> I can see the benefits of your proposal.
>>
>> Its only drawback is that it would force admins to
>> configure a web.xml for their docroot, even if the docroot contained
>> only static resources that didn't require any protection.
>
>
> Not necessarily. If you look at issue
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=731,
>
> the deployment backend allow deploying a web-app that doesn't have a
> web.xml :-). To test it, just do in domain.xml:
>
> Add
>
> > <web-module availability-enabled="false" context-root="/default"
> directory-deployed="true" enabled="true"
> location="${com.sun.aas.instanceRoot}/docroot" name="default"
> object-type="system-all">
> > <!-- System Web Module - DO NOT DELETE! -->
> > </web-module>
If you have this entry in domain.xml, the web container will load it as
a web module since the domain.xml indicates the module type as web. The
loading part doesn't go through deployment code path.
When we need to redeploy this module and if we go through deployment
code path, we do need the web.xml present to tell us this is a web
module (we cannot tell the module type from archive suffix if we do
directory deployment). We could probably do some special handling for
this application in deployment code, but as I understand, that's not our
intention. We wanted to make this application to go through the normal
deployment path (i.e. no hack).
>>
>> We also need to keep in mind that at some point we probably need to
>> port the "multiple docroot" feature that was available in iAS 7.x and
>> reimplemented in SJSAS 8.2 EE to GlassFish. This feature allows
>> configuration of additional URI-to-docroot mappings, so your proposal
>> would also apply to it.
>
>
> Well, that's an EE WebServer features :-) Just kidding. I think it is
> more important to fix the current behavior, and then build on top of it.
I agree we need to fix the current behavior first. Though we need to
take this into consideration so our design is easily extended later.
Thanks,
- Hong