Hi Dies,
I agree with you that wrapping the stream to a resource with a stream class
sounds a better approach. I am assuming that same approach could also be
applied to the auto discovery process when a given resource (jar) is changed
after the initial deployment. The proposed classloader could ping the
resources at periodic time intervals and if there is a change in a given
resource, and if variables are configured appropriately, the classloader
could explicitly close the stream for the old resource and automatically
reload the new resource - all within a single transaction context. There
might be some synchronization challenges in a clustered topology, but for
now, we can leave the responsibility of making sure the resources are
identical with the end user.
Vishal
On Thu, Feb 5, 2009 at 10:42 PM, Dies Koper <diesk_at_fast.au.fujitsu.com>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,
> 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: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>