[jira] Commented: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource

2009-07-01 Thread Ivan (JIRA)

[ 
https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726344#action_12726344
 ] 

Ivan commented on XBEAN-133:


With viola.lu's new patch, I tried to build Geronimo 2.2 and OpenEJB 2.1.3, not 
errors occurred. Seems all the junit cases passed.

> Jar file is not close after open resulting in files delete failure when 
> finding resource
> 
>
> Key: XBEAN-133
> URL: https://issues.apache.org/jira/browse/XBEAN-133
> Project: XBean
>  Issue Type: Bug
>  Components: finder
> Environment: os:win2003
>Reporter: viola.lu
>Assignee: David Blevins
>Priority: Minor
> Attachments: XBean-133.patch
>
>
> 1.Deploy a war including jar files under lib with a wrong deployment plan in 
> Geronimo server
> 2.Fail to deploy but can't recursive delete files under lib coz jar files are 
> open not close by xbean resource finder
> Refer to https://issues.apache.org/jira/browse/GERONIMO-4696 for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource

2009-06-30 Thread Ivan (JIRA)

[ 
https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725900#action_12725900
 ] 

Ivan commented on XBEAN-133:


Thanks David for your response.
In Geronimo, the cache is closed once the server is started, it is due to the 
URLJarFile memory leak. Depends on whether the cache is opened or not, 
different jar instance is returned by the gerJarFile method. 
If it is opened, the same instance of sun.net.www.protocol.jar.URLJarFile is 
returned, no matter which url you are using, they always return the same 
jarFile instance, that is why I add this condition, if the cache is on, we 
should never close the jarFile.
If it is closed, different java.util.jar.JarFile instance is returned.
I have not tried it with OpenEJB, I will checked it later.


@Test
public void testJarURLConnection2() throws Exception {
//Comment out the line below to determine whether or not trun of the 
cache
//new URL("http://a";).openConnection().setDefaultUseCaches(false);
URL url1 = new URL("jar", "", 
"file:/C:/m2/activeio/activeio/2.0-r118/activeio-2.0-r118.jar!/");
JarURLConnection jarConn1 = (JarURLConnection) url1.openConnection();
JarURLConnection jarConn2 = (JarURLConnection) url1.openConnection();
JarFile jarFile1 = jarConn1.getJarFile();
System.out.println(jarFile1 + " is get from jarConn1");
JarFile jarFile2 = jarConn2.getJarFile();
System.out.println(jarFile2 + " is get from jarConn2");
//
URL url2 = new URL("jar", "", 
"file:/C:/m2/activeio/activeio/2.0-r118/activeio-2.0-r118.jar!/");
System.out.println(((JarURLConnection) 
url2.openConnection()).getJarFile());
//
URL url3 = ((JarURLConnection) url2.openConnection()).getJarFileURL();
JarURLConnection jarConn31 = (JarURLConnection) new URL("jar", "", 
url3.toExternalForm() + "!/").openConnection();
JarFile jarFile31 = jarConn31.getJarFile();
System.out.println(jarFile31);
//
URL url4 = new URL("jar", "", 
"file:/C:/m2/activeio/activeio/2.0-r118/activeio-2.0-r118.jar!/META-INF/MANIFEST.MF");
JarURLConnection jarConn41 = (JarURLConnection) url4.openConnection();
JarFile jarFile41 = jarConn41.getJarFile();
System.out.println(jarFile41);
//
URL url5 = ((JarURLConnection) url4.openConnection()).getJarFileURL();
JarURLConnection jarConn51 = (JarURLConnection) new URL("jar", "", 
url5.toExternalForm() + "!/").openConnection();
JarFile jarFile51 = jarConn51.getJarFile();
System.out.println(jarFile51);
}


> Jar file is not close after open resulting in files delete failure when 
> finding resource
> 
>
> Key: XBEAN-133
> URL: https://issues.apache.org/jira/browse/XBEAN-133
> Project: XBean
>  Issue Type: Bug
>  Components: finder
> Environment: os:win2003
>Reporter: viola.lu
>Assignee: David Blevins
>Priority: Minor
> Attachments: XBEAN-133.patch
>
>
> 1.Deploy a war including jar files under lib with a wrong deployment plan in 
> Geronimo server
> 2.Fail to deploy but can't recursive delete files under lib coz jar files are 
> open not close by xbean resource finder
> Refer to https://issues.apache.org/jira/browse/GERONIMO-4696 for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource

2009-06-30 Thread Ivan (JIRA)

[ 
https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725552#action_12725552
 ] 

Ivan commented on XBEAN-133:


Generally speaking, the jarFile is in the method domain,  it should be released 
soon. But, if we could explicitly call the close method will be better.
After some investigation, whether or not we could invoke the close method, I 
think it depends on.  If the usercache is closed and url is recreated to point 
to the jarFile (like what is done in the findResource method), each call to 
openConnection().getJarFile() will return a different JarFile object , which 
means that calling the close method would not affect others who uses the same 
Jar file.
So, shall we change the patch to something like
 if (jarfile != null && !conn.getUseCaches())
try {
 jarfile.close();
} catch (Exception e) {
}
Not sure whether I made a mistaken, thanks for any comment !

> Jar file is not close after open resulting in files delete failure when 
> finding resource
> 
>
> Key: XBEAN-133
> URL: https://issues.apache.org/jira/browse/XBEAN-133
> Project: XBean
>  Issue Type: Bug
>  Components: finder
> Environment: os:win2003
>Reporter: viola.lu
>Assignee: David Blevins
>Priority: Minor
> Attachments: XBEAN-133.patch
>
>
> 1.Deploy a war including jar files under lib with a wrong deployment plan in 
> Geronimo server
> 2.Fail to deploy but can't recursive delete files under lib coz jar files are 
> open not close by xbean resource finder
> Refer to https://issues.apache.org/jira/browse/GERONIMO-4696 for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (XBEAN-133) Jar file is not close after open resulting in files delete failure when finding resource

2009-06-29 Thread viola.lu (JIRA)

[ 
https://issues.apache.org/jira/browse/XBEAN-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725169#action_12725169
 ] 

viola.lu commented on XBEAN-133:


As we know, when call jarfile.close() method,  it will close all previously 
streams invoked by getInputStream, this may mis-close other InputStreams not 
realted to this jar file, 
I don't know whether this will have a side effect for xbean ResourceFinder, can 
somebody give some hints?Thanks.

> Jar file is not close after open resulting in files delete failure when 
> finding resource
> 
>
> Key: XBEAN-133
> URL: https://issues.apache.org/jira/browse/XBEAN-133
> Project: XBean
>  Issue Type: Bug
>  Components: finder
> Environment: os:win2003
>Reporter: viola.lu
>Assignee: viola.lu
>Priority: Minor
> Attachments: XBEAN-133.patch
>
>
> 1.Deploy a war including jar files under lib with a wrong deployment plan in 
> Geronimo server
> 2.Fail to deploy but can't recursive delete files under lib coz jar files are 
> open not close by xbean resource finder
> Refer to https://issues.apache.org/jira/browse/GERONIMO-4696 for details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.