Hi Jeanfrancois,
Jeanfrancois Arcand wrote On 06/12/06 13:30,:
>>
>> I guess docroot was always intended as a short-cut for mapping a
>> virtual server's root context to a directory containing only static
>> resources that don't require any protection.
>
>
> Right, but as soon as the user configure the default web-module, that
> value no longer works/used, which makes the docroot property
> completely useless.
Yes, the docroot property will be shadowed by the default-web-module,
but once
the default-web-module has been undeployed, the docroot property should
become
effective again.
>
>>
>> If admins wanted to have a virtual server's root context treated as a
>> regular webapp, they would specify a default-web-module for that
>> virtual server (just like the "__asadmin" virtual server currently
>> does), which would override the virtual server's docroot property.
>>
>> [A separate question would be if the container's implicit servlet
>> mappings (e.g., for JSPs) should also be applied to a docroot. In
>> other words, should a ".jsp" resource in a docroot be treated as a
>> static resource or a JSP?]
>>
>> I think it is OK for the deployment code or AMX to not know anything
>> about our "dummy webmodule" (or "hack" as you put it :), since that
>> really is an implementation detail.
>> I don't see why we need a separate admin event or API to fall back to a
>> virtual server's docroot after
>>
>> - a webmodule designated as the virtual server's default-web-module, or
>> - a webmodule with a context-root of "/" in sun-web.xml
>>
>> has been undeployed. Couldn't we just reinstantiate the "dummy
>> webmodule"
>> ourselves when that happens?
>
>
> How will you do that ;-)? The current problem we are facing is we have
> no way to determine if the default web module have been REPLACED or
> REMOVED.
>
> [Scenario A - REPLACED]
> User replaces the default-web module with AppA.
>
> Internally, we undeploy "/", then deploy AppA.
>
> All of this is done via classes
> com.sun.enterprise.server.WebModuleDeployEventListener, which get
> event for first unload module "/", then load module "AppA".
>
> [Scenario B - REMOVED]
>
> User undeploy AppA.
>
> com.sun.enterprise.server.WebModuleDeployEventListener will get event
> for unload "/" (which is AppA).
>
> Then nothing happens...and we ends up with nothing at "/", so the next
> HTTP request cannot be mapped to "/". [Scenario B] can be supported
> properly only and only if the backend (the class that call
> WebModuleDeployEventListener) knows something about the "hacked" web
> app, which is not the case right now.
>
> On the WebContainer side, what can we do....nothing since how can we
> determine we are processing scenario A or B?
Couldn't we blindly restore the dummy-web-module whenever a webapp
that used to be deployed at "/" gets undeployed?
In scenario [A], the dummy-web-module would be stored at "/" for a very
short amount of time: between the undeploy (of the default-web-module)
and deploy (of AppA) events. As soon as AppA gets deployed, it will replace
the dummy-web-module.
In scenario [B], the dummy-web-module would remain at "/" until another
web module gets deployed there.
Jan
>
> We gonna need a special event if we want to support this on the
> WebContainer side, which will be another hack IMO.
>
>>
>> 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.
>
> Thanks
>
> -- Jeanfrancois
>
>>
>> Thanks,
>>
>> Jan
>>
>>
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>