Hi Jan,
Thank you for your detailed reply.
I have created an issue to track the enhancement.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=7149
I do think a better solution is to do what the EJBClassLoader does,
instead of just disabling antiJARLocking.
What EJBClassLoader does in its getResource (findResource0 really) and
getResourceAsStream methods is, it wraps the stream to a resource with a
special stream class (SentinelInputStream) that has a close method. When
an application is redeployed, the container calls a method in the
EJBClassLoader that will close all streams of the resources explicitly.
This is much more reliable than waiting for the gc to kick in. It also
solves the problem of the URL connection's caching not disabled by the
user application.
I don't think making antiJARLocking user configurable is the way to go,
especially when it is possible to solve the problem completely.
Thanks,
Dies Koper
Jan Luehe wrote:
> 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