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?
Thanks
-- Jeanfrancois