JDK-5098318 : Cached Jar file should be released on appl. exit even that is opended by Cipher
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 1.4.2_05
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-09-08
  • Updated: 2005-09-16
  • Resolved: 2005-09-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_10Fixed 6 betaFixed
Related Reports
Relates :  
JDK-6423370 - Fix for bug 5098318 prevents caching of JAR files containing cipher code
Relates :  
JDK-6321722 - On windows, sometimes jar file cannot be deleted even when there is no reference to it
Relates :  
JDK-5041014 - URLClassLoader.getResourceAsStream locks jar files
Description
A customer found the case where files in .war can not be deleted
in some Web application which uses  javax.crypto.Cipher 
even if undeploy are executed.

CONFIGURATION:
 JDK:JDK1.4.2_05
 Tomcat 5.0.25 


BEHAVIOR :
 The files under webappls directory can not be deleted after undeploy 
 with Tomcat Manager.
 Because the files are not deleted, application can not be deployed 
 after the customer changes the application.
 
.........
        at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:67)
        at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.ja
va:85)
        at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection
.java:69)
        at javax.crypto.SunJCE_e.run(DashoA6275)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.SunJCE_d.b(DashoA6275)
        at javax.crypto.SunJCE_d.a(DashoA6275)
        at javax.crypto.SunJCE_d.a(DashoA6275)
        at javax.crypto.SunJCE_b.b(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.SunJCE_g.a(DashoA6275)
        at javax.crypto.SunJCE_g.a(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.Cipher.a(DashoA6275)
        at javax.crypto.Cipher.getInstance(DashoA6275)
        at HelloWorld.encode(HelloWorld.java:41)
        at HelloWorld.init(HelloWorld.java:17)
        at javax.servlet.GenericServlet.init(GenericServlet.java:211)


INVESTIGATION :
   It turned out the jar file included in the appication is saved  in cache of
   sun.net.www.protocol.jar.JarFileFactory called from  javax.crypto.Cipher.
   We can control cache on/off with using setUseCaches(false) in usual our
   application. However, in the above case, because the cache control is done 
   in javax.crypto.Cipher, we can not do anything to control cache.

REQUEST:
  If Cipher really opens jars in user application and hold,
  it seems that Cipher should release or purge cached jars on the application's
  exit.
  Otherwise, please provide some workaround.

======================================================================
Comments
EVALUATION 6321722 was filed, and following promotion of that fix (b59), Valerie reports: ======== Both the modified (which I modified to remove the dependency on JCE) and the original (which uses JCE) testcase work as expected, i.e. fail on b58 and pass on b59. Guess we finally have this hard-to-trace bug nailed down and fixed. :) ======== Yay...that burned way too many cycles!
15-11-2005
EVALUATION I generated another testcase based on the current testcase but without calling into JCE. This looks very much like a GC issue as the test is very fickle and there is no single API call which would cause the behavior to change. Anyway, I've filed 6321722 "On windows, sometimes jar file cannot be deleted even when there is no reference to it" to keep track of this. Thus, I have attached the JCE regression test (JarCachingTest.java) for verifying the fix in mustang.
08-09-2005
EVALUATION As part of JCE export requirement, JCE framework has mechanisms which would check the crypto configuration of the system (JCE jurisdiction policy file) and the calling apps (optional permission files bundled with the app) and determine the available crypto algorithms and their max key length. Thus, JCE framework would access caller codebase as well as several other jars in order to determine the allowed crypto strength. The accesses are through JarURLConnection and caching is on *by default*. The current JarURLConnection impl does not seem to allow its callers to purge or delete the cached jars. Will have to disable caching unless the current JarURLConnection impl can be fixed/enhanced to support the file purging. ###@###.### 2004-11-19 22:33:57 GMT ###@###.### 2004-11-19 22:34:10 GMT We have provided a fix in 1.4.2_10 that also works in tiger, but for some reason the same fix is not working in mustang. I'm pretty sure the problem is in either the GC or in the Zip file code. I took a large chunk of the JCE jar verification code out, and watched it iterate over the 8 jar entries (skipping the rest) and it worked fine, but on the 9th (skipping the rest), it failed. I'm pretty sure it's GC, but need to move the zip/jar code from tiger into mustang to remove this possibility. ###@###.### 2005-06-07 00:13:39 GMT
19-11-2004