Alternate Docroots in Web Applications

Alternate Docroots in Web Applications

GlassFish v2 Build 40 adds support for alternate docroots to web applications. Previously, support for alternate docroots was limited to virtual servers.

Alternate docroots allow web applications to serve requests for certain resources from outside their own docroot, based on whether those requests match one (or more) of the URI patterns of the web application's alternate docroots.

This means that web applications no longer need to bundle all their resources. Instead, part of their resources may be outsourced into server directories outside the web application's docroot, so-called alternate docroots, where they may be shared with other web applications.

If a request matches an alternate docroot's URI pattern, it will be mapped to the alternate docroot by appending the request URI (minus the web application's context root!) to the alternate docroot's physical location (directory).

The URI patterns of alternate docroots of web applications support exact, path prefix, and extension matches, just like their counterparts for virtual servers. If a request matches multiple URI patterns, the alternate docroot is determined according to the following precedence order:

1. Exact match
2. Longest path match
3. Extension match

Alternate docroots of web applications are configured as sun-web.xml properties, using the same syntax as alternate docroots for virtual servers.

Example: The following sun-web.xml specifies 3 alternate docroots:

<sun-web-app>
  <property name="alternatedocroot_1" value="from=/my.jpg dir=/srv/images/jpg"/>
  <property name="alternatedocroot_2" value="from=*.jpg dir=/srv/images/jpg"/>
  <property name="alternatedocroot_3" value="from=/jpg/* dir=/src/images"/>
</sun-web-app>

The value of each alternate docroot has two name-value components: The first component (with name from) specifies the alternate docroot's URI pattern as its value, and the second component (with name dir) specifies the alternate docroot's physical location (directory) as its value.

In this example, the URI pattern of the first alternate docroot uses an exact match, whereas the URI patterns of the 2nd and 3rd alternate docroots use extension and path prefix matches, respectively.

Assume the above sun-web.xml belongs to a web application deployed at http://<host>:<port>/myapp.

The first alternate docroot will cause any requests with this URL:

  http://<host>:<port>/myapp/my.jpg

to be mapped to this resource:

  /svr/images/jpg/my.jpg

while the 2nd alternate docroot will cause any requests with a *.jpg suffix, as in:

  http://<host>:<port>/myapp/*.jpg

to be served from this physical location:

  /svr/images/jpg

whereas the 3rd alternate docroot will cause any requests whose URI starts with /myapp/jpg/, as in:

  http://<host>:<port>/myapp/jpg/*

to be served from the same directory as the 2nd alternate docroot.

For example, the 2nd alternate docroot maps this request:

  http://<host>:<port>/myapp/abc/def/my.jpg

to:

  /srv/images/jpg/abc/def/my.jpg

and the 3rd alternate docroot maps:

  http://<host>:<port>/myapp/jpg/abc/resource

to:

  /srv/images/jpg/abc/resource

If a request does not match any of the target web application's alternate docroots, or if the target web application does not specify any alternate docroots, the request will be served from the web application's standard docroot, as usual.

Posted at 06:36PM Mar 21, 2007 by Jan Luehe in Sun  |  Comments[4]

Access Log Patterns and Nicknames

Access Log Patterns and Nicknames

GlassFish v2 makes it easier to specify well-known access log patterns, by allowing you to specify access log patterns by their well-established nicknames.

In GlassFish, you normally use the format attribute of the <access-log> subelement of <http-service> to specify the access log pattern of your virtual servers.

The default access log pattern looks like this:

  format="%client.name% %auth-user-name% %datetime% %request% %status% %response.length%"

The above are just a subset of the access log pattern tokens supported by GlassFish. The complete list of access log pattern tokens, from which you can assemble your own custom access log pattern, is as follows:

  %auth-user-name%
  %client.dns%
  %client.name%
  %cookie.value%
  %datetime%
  %header.accept%
  %header.%
  %header.auth%
  %header.date%
  %header.if-mod-since%
  %header.user-agent%
  %header.referer%
  %http-method%
  %http-uri%
  %http-version%
  %query-str%
  %referer%
  %request%
  %response.length%
  %status%
  %user.agent%
  %vs.id%

Due to popular demand, GlassFish v2 supports shortcuts for well known access log patterns, allowing you to specify an access log pattern by its nickname, instead of having to list its constituent tokens.

Currently, the following access log pattern nicknames are supported:

• common, for the "common" access log pattern from Apache
• combined, for the "combined" access log pattern from Apache

Additional nicknames will be added in the future, based on the GlassFish community's input.

So, in order to change the access log pattern from the GlassFish default to Apache's "common" format, all you need to do is issue the following asadmin command (or use the admin gui):

  asadmin set server.http-service.access-log.format="common"

or to change it to Apache's "combined" format, issue this command:

  asadmin set server.http-service.access-log.format="combined"

Provided that access logging has been enabled, the above commands will take effect immediately, without requiring a server restart.

Posted at 10:09AM Mar 09, 2007 by Jan Luehe in Sun  |  Comments[5]

Presentation on Virtual Hosting Features in GlassFish

Presentation on Virtual Hosting Features in GlassFish

Please see the slides of my presentation I gave at the GlassFish User Experience meeting on 03/07/2007, which covers the info from my related blog, plus recent updates.

Posted at 11:45AM Mar 08, 2007 by Jan Luehe in Sun  |  Comments[0]