Craig,
Craig McClanahan wrote On 08/29/06 19:33,:
> 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.
I see your point, but the servlet spec does not cover any
default-web-module configuration,
which is SJSAS/GlassFish specific.
>
> 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?
We already do that.
If a virtual server does not specify any default-web-module, we
construct a "dummy" web module
from its docbase location (and register it at "/"), but we also support
dynamic content in this
case, since this "dummy" web module inherits the configuration
(including the JspServlet declaration)
from default-web.xml.
On the other hand, if a virtual server does specify a
default-web-module, the requirements
for its default-web-module are that it may reference a "full" webapp
(any webapp already
deployed on the virtual server), with both static and dynamic contents.
Consider the JSF-based "admingui" webapp, which is currently declared as
the default-web-module
of the "__asadmin" virtual server, as an example.
Jan
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>