"adrian(a)jboss.org" wrote :
| I guess it would need something to explictly close()
| the URLConnection or JarFile created in the JARHandler constructor
| when it is unpacked and replaced?
|
How are you gonna do that? :-)
Since URLConnection doesn't have anything useful to do a close.
See below for more info.
"adrian(a)jboss.org" wrote :
| i.e. My guess is something is keeping a reference previous
| packed VirtualFile and hence to the JarFile which means the
| connection/file handle is kept open.
|
When we do lastModified, for HDScanning purposes, we mostly use
URLConnection::getLastModified, which is probably the cause for open handle.
See URLExistsUnitTestCase in JBossVFS.
In the case of non-jar file, I was able to do this hacky thing:
| InputStream in = conn.getInputStream();
| long lastModified;
| try
| {
| lastModified = conn.getLastModified();
| System.out.println("lastModified, "+lastModified);
| assertNotSame("lastModified", 0, lastModified);
| }
| finally
| {
| in.close();
| }
| assertTrue(tmp.getAbsolutePath()+" deleted", tmp.delete());
|
Open/close input stream, and was then allowed to delete the file.
W/o this, you cannot delete the file.
But in the case of jar file, see 2nd test in URLExistsUnitTestCase, I cannot do the same
hack, since it complains about not specifying the entry:
| java.io.IOException: no entry name specified
| at
sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129)
| at
org.jboss.test.virtual.test.URLExistsUnitTestCase.testJarURLs(URLExistsUnitTestCase.java:102)
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145764#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...