Jan Luehe wrote On 08/29/06 17:59,:
> 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).
There's been internal discussion about the potential impact of this
proposed change on monitoring and JSR 77.
The proposed change should not result in any spec violation, but it will
reduce the number of monitoring mbeans.
Here's an example:
Consider web module "123" with context root "/123", which is declared
as the default web module of virtual server "server".
What we used to do:
1. Deploy a *copy* of "123" to "/"
2. Deploy "123" to "/123".
Each of these deployments results in the creation of corresponding
monitoring mbeans, etc.
What the proposed change will do:
Deploy "123" to "/123" (which will result in the creation of
corresponding
monitoring mbeans), but also map requests for "/" to it (via an
internal mapping algorithm).
So you'll still see monitoring mbeans getting registered for "123", but
instead of
seeing 2 sets of monitoring mbeans, you'll see just one set.
Jan
>
> 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
>
>