Hi Dies,
On 02/05/09 22:42, Dies Koper wrote:
> 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 for filing the issue!
I will certainly explore the approach the EJBClassLoader has taken.
Thanks,
Jan
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: webtier-help_at_glassfish.dev.java.net
>