Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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: kconner
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: 2018-03-29 21:55 UTC (History)
3 users (show)

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


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.