[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: File locking

[alesj]

"adrian at 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 at 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#4145764

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145764