Hi Jan,
Jan Luehe wrote:
> Hi Jeanfrancois,
>
> Jeanfrancois Arcand wrote On 06/09/06 14:18,:
>
>> Hi,
>>
>> In GlassFish we have the concept of a default web-module associated with
>> a virtual-server. The default web-module is located under:
>>
>> http://localhost:8080/
>>
>> mapped to "/".
>>
>> Every virtual-server has a default web-module. When you install
>> GlassFish, you usually have two virtual-server created (asadmin and
>> server). asadmin is the one used by the admin backend (CLI & GUI), and
>> "server" is the one you deploy your application on it. This default
>> web-module is configurable using admin CLI or GUI.
>>
>> The server default web-module after a new GlassFish installation is
>> not a real web application, but a special web application that can
>> only serve static pages. This behaviour is something inherited from
>> SJS WS 6.x in AS 7.x to allow easy static content addition to the "/"
>> context root, without any deployment steps. But right now, the
>> functionality is buggy (see bug 6409163, 483, 441, etc.) and some
>> important features are missing.
>>
>> All the issues happens because the default web-module for newly created
>> virtual-server is a "hack" internally, and other components (AMX,
>> Deployment) are not aware of this special web-module. As an example,
>> when a user defined default web-module is undeployed, the deployment
>> backend doesn't know what to do to re-install the "hack" since there
>> is no API availble that state: re-add the hacked default web-module.
>> Of course we can add such API, but that will make the hack more ugly
>> than now. Not to say that it is impossible to securely protect this
>> special web application, because there is no web.xml support for that
>> special web application.
>>
>> To fix all of those issues, I would like to propose we create a new
>> system web application, witch support web.xml/sun-web.xml, exposed in
>> domain.xml like other system apps. This way the web and the deployment
>> team can properly implement the logic (and I can clean the embarassing
>> code :-)). The system web-app will be deployed at the same location as
>> now (for backward compatibility):
>>
>> ${glassfish.home}/domains/domain/docroot
>>
>> And will support the same functionalities, except it will also contains a
>>
>> ${glassfish.home}/domains/domain/docroot/WEB-INF
>>
>> folder with a proper web.xml/sun-web.xml.
>>
>> The drawback of this approach is if people changes the value of the
>> virtual-server "docroot" property:
>>
>>> <virtual-server hosts="${com.sun.aas.hostName}"
>>> http-listeners="http-listener-1,http-listener-2" id="server"
>>> log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
>>> <property name="docroot"
>>> value="${com.sun.aas.instanceRoot}/docroot"/>
>>
>>
>> then the new value will need to point to a valid web application, not
>> a static folder like now. We can also remove support for that property
>> since it conflict with the normal way of configuring the default
>> web-module, which is by using admin CLI or GUI. I would be in favor of
>> removing that property.
>>
>> Any thought?
>
>
> 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>
Modify:
> <virtual-server default-web-module="default"
hosts="${com.sun.aas.hostName}"
http-listeners="http-listener-1,http-listener-2" id="server"
log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
Add:
> <application-ref disable-timeout-in-minutes="30" enabled="true"
lb-enabled="false" ref="default" virtual-servers="server"/
Then the default web-module is the one under
${com.sun.aas.instanceRoot}/docroot
>
> 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.
>
> 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?
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
>
>