Jan,
Thinking about this proposal with respect to the servlet spec
requirements for web applications makes me wonder if this matches up
with the letter of the requirements -- it certainly doesn't match up
with the spirit, from what I can see.
An alternative to think about -- unless the domain has explicitly
defined a default web module, how about configuring something super
simple that only serves static content? That would cover lots of use
cases for things like someone just requesting "
http://localhost:8080" --
which, under your scheme, would redirect them to some other webapp. The
startup time would be really small, and anyone who wanted a real webapp
mapped to the root URL could still do so.
Craig
Jan Luehe wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>