webtier@glassfish.java.net

Re: purpose of extracting jars in web apps to generated directory?

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Thu, 05 Feb 2009 20:32:19 -0800

Hi Dies,

On 02/03/09 19:47, Dies Koper wrote:
> Hi Jan,
>
> I have a question about the implementation of WebappClassLoader.
>
> When including a jar with resources in a web app's WEB-INF/lib, at the
> moment a resource is first accessed from the application the jar's
> contents is extracted into the generated directory.
>
> This means that when there are many resources in a jar, there is a long
> delay when accessing the first resource. This is also noticeable when
> accessing the admin console each time after starting the domain.
>
> Do you know why is it implemented this way?
>
> I figured the reason is to work around redeployment problems due to file
> locks on jar files. If this is the case, have you considered redesigning
> the web classloader in the same way the EJB classloader is designed,
> i.e. closing the open streams when the classloader is discarded during
> re-/undeployment?
>
>

GlassFish inherited this behaviour from Tomcat.
The motivation for it is summarized in this Tomcat FAQ entry:

  I want to redeploy web applications, how do I prevent resources from
  getting locked?

  Most locking issues will occur with JARs from /WEB-INF/lib, and are
  useally caused by access through URLs. Tomcat has mechanisms to allow
  avoiding locking. In Tomcat 5.0, a mechanism exists to prevent locking
  when accessing resources using the getResource method of the URL
  classloader (many applications, such as Xerces, do not set the use of
  caching to false before opening the URL connection, causing
  locking). If such a call occurs, resources inside the JARs will be
  extracted to the work directory of the web application. In Tomcat 5.5,
  this mechanism is disabled by default (as it has a non negligible
  influence on startup times, and is often useless), and can be enabled
  using the antiJARLocking attribute of the Context element.

GlassFish still enables antiJARLocking by default, and currently does
not provide any way of turning it off.

We should definitely support a way of turning antiJARLocking off
(and might want to consider turning it off by default), by honoring
the antiJARLocking attribute in Tomcat's context.xml, and adding a
similar property to sun-web.xml.

Thanks for bringing this up. I'll work on it, but feel free to file
an ENHANCEMENT request in IssueTracker.


Jan

> Thanks,
> Dies
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>