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
>
>