Hi Hong,
Hong Zhang wrote:
> 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).
Thanks for the info. That means we gonna need to require an empty
web.xml if we want to implement it properly.
-- Jeanfrancois
>
>>>
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>