[ 
https://issues.apache.org/jira/browse/WICKET-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242414#comment-13242414
 ] 

Tim Quinn commented on WICKET-4458:
-----------------------------------

Hi, Martin.

I don't know of any doc that states categorically that JarURLConnection behaves 
this way but as you said the JavaDoc leaves that option open to the 
implementation.  It has been a while but I remember reading the relevant Java 
SE source code and finding exactly this caching behavior.  I do not know if 
this applies in the lsof experiment you ran, but GC can trigger JAR closes so 
it can be very unpredictable when to expect the file to be left open vs. 
closed.  


                
> wicket-core-1.5.5.jar not closed when Application is undeployed from directory
> ------------------------------------------------------------------------------
>
>                 Key: WICKET-4458
>                 URL: https://issues.apache.org/jira/browse/WICKET-4458
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.5
>         Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
>            Reporter: bernard
>
> How to reproduce:
> - Create a 1.5.5 quickstart
> - deploy it on the GlassFish server with directory deployment (I use NetBeans 
> which is easy)
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Error in GlassFish log:
> Unable to delete file WEB-INF\lib\wicket-core-1.5.5.jar
> I first thought that this was a GlassFish issue such as:
> http://java.net/jira/browse/GLASSFISH-17339
> To eliminate that, I added glassfish\modules\war-util.jar to the project and 
> wrote code to let GlassFish close all jar files:
> In the Application class:
>     @Override
>     public void onDestroy() {
>         super.onDestroy();
>         ClassLoader parentClassLoader = this.getClass().getClassLoader();
>         ClassLoader classLoader;
>         do{
>             classLoader = parentClassLoader; 
>             if(classLoader instanceof WebappClassLoader){
>                 WebappClassLoader glassFishLoader = 
> (WebappClassLoader)classLoader;
>                 glassFishLoader.closeJARs(true);
>                 break;
>             }
>             parentClassLoader = classLoader.getParent();
>         }while(parentClassLoader != classLoader && parentClassLoader != null);
>         
>     }
>       
> but this did not fix the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to