Bug 1058283 - Classloading followed by JAR-file deleting on windows machines results in "java.lang.RuntimeException: Unable to delete file"
Summary: Classloading followed by JAR-file deleting on windows machines results in "ja...
Keywords:
Status: ON_QA
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: Rules / jBPM integration
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: DR1
: 6.1.0
Assignee: Rob Cernich
QA Contact: Matej Melko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-27 12:47 UTC by Martin Basovník
Modified: 2023-05-15 19:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
An error is thrown when deleting certain JAR files on Windows systems. When users attempt to delete JAR files that are being used by the classloader, a message will appear reading "java.lang.RuntimeException: Unable to delete file". This behaviour is only apparent in a Windows environment. To work around this, ensure the files are not in use when you are attempting to delete them.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Martin Basovník 2014-01-27 12:47:43 UTC 
Description of problem:

Deleting of JAR files is failing when classloader keeps some objects in memory (on windows machines)! Windows will not let you delete files that are in-use, but Linux will.
=> @see http://stackoverflow.com/a/11273404

Problematic tests (e.g.)
1) org.drools.compiler.kproject.KieProjectDefaultClasspathTest#createMultpleJarAndFileResources
2) org.drools.compiler.kproject.KieProjectCDITest#createMultpleJarAndFileResources
3) org.drools.compiler.kproject.KieProjectRuntimeModulesTest#createMultpleJarAndFileResources

Classloader will not be used after finally statement (example 1 and 2) but it is beeter to add statement "System.gc()". It is not guaranteed that JAR file is closed when deleting (by FileManager#tearDown()) but it inceareses the probability..

If java 7 is used we can use URLClassLoader#close() (http://docs.oracle.com/javase/7/docs/api/java/net/URLClassLoader.html#close%28%29)


Version-Release number of selected component (if applicable):


How reproducible:
sometimes

Steps to Reproduce:
1. Execute any of problematic tests with classloader + filemanager on windows machines.


Actual results:
Error Message
Unable to delete file:C:\Documents and Settings\hudson\Local Settings\Temp\__drools__1a47d35d-c891-49b8-b153-9ca296a6c62e\jar1-1.0-SNAPSHOT.jar
Stacktrace
java.lang.RuntimeException: Unable to delete file:C:\Documents and Settings\hudson\Local Settings\Temp\__drools__1a47d35d-c891-49b8-b153-9ca296a6c62e\jar1-1.0-SNAPSHOT.jar
	at org.drools.core.util.FileManager.deleteFile(FileManager.java:129)
	at org.drools.core.util.FileManager.deleteDir(FileManager.java:102)
	at org.drools.core.util.FileManager.tearDown(FileManager.java:45)
	at org.drools.compiler.kproject.AbstractKnowledgeTest.tearDown(AbstractKnowledgeTest.java:53)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


Expected results:
Temporary files are deleted by FileManager.

Additional info:
Note You need to log in before you can comment on or make changes to this bug.