The way a virtual server's default-web-module has been implemented
is going to change, in order to optimize server startup
(see
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1024).
Some background: A virtual server's default-web-module is deployed at
a virtual server's root context ("/"). It is used to serve any
requests that cannot be mapped to any of the virtual server's other
deployed contexts. Any webapp deployed on a virtual server may be
declared as the virtual server's default-web-module.
Up until now, the container used to treat a default-web-module as a
separate webapp with its own name (derived from the name of the
backing webapp by prepending "__default-" to it), lifecycle, and
classloader. For example, the web module named "admingui" is declared
as the default-web-module of the virtual server with id "__asadmin",
and is deployed at the context root "/asadmin" (as a webapp with name
"asadmin") and at __asadmin's root context (as a webapp with name
"__default-admingui").
Implementing a default-web-module as a separate webapp is inefficient,
as it causes the backing webapp to be initialized twice. For example, you've
been used to seeing this logging output in server.log:
Initializing Sun's JavaServer Faces implementation (1.2-b20-FCS) for
context '/asadmin'
Completed initializing Sun's JavaServer Faces implementation
(1.2-b20-FCS) for context '/asadmin'
Initializing Sun's JavaServer Faces implementation (1.2-b20-FCS) for
context ''
Completed initializing Sun's JavaServer Faces implementation
(1.2-b20-FCS) for context ''
Implementing a default-web-module as a separate webapp also increases
memory footprint, as the same webapp is deployed twice and consumes
twice the number of resources.
From now on, a default-web-app will no longer be treated as a separate
webapp. Instead, the container's request mapper will be notified
whenever a webapp also acts as a virtual server's default-web-app, and
will map any requests for the default-web-app to its backing
webapp. For efficiency reasons, the URIs of requests for a
default-web-app will not be modified as they are mapped to the context
root of the backing webapp, however, any of the servlet request API methods
will return the mapped request components.
For example, consider webapp "123" declared as the default-web-app of
the virtual server named "server". Assume this webapp contains a
servlet TestServlet which prints the result of
HttpServletRequest.getContextPath(). The webapp's TestServlet may be
accessed as:
http://<host>:<port>/123/TestServlet
or
http://<host>:<port>/TestServlet
The result of HttpServletRequest.getContextPath() will now be equal to
"/123"
for either invocation (instead of the 2nd invocation returning the empty
string "").
Please let me know if your code has any dependencies on webapps whose
names are prefixed with "__default-", or has relied on the fact that
a default-web-app used to be implemented as a separate webapp.
Thanks,
Jan