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