The whole temp file thing seems to have arisen from JDK inconsistency issues related to the ClassLoaderUtil.clearSunJarFileFactoryCache method.
This method was for a period failing to actually release the file handle on jar files due to some real spaghetti in the sun.net.www.protocol.jar.JarFileFactory. On unix like systems the file was never locked and the jars remained silently referenced in the JarFileFactory. When the jars are reloaded on redeployment the unix JarFileFactory doesn't even know that the files were unloaded as the File reference is still valid. On windows the JarFileFactory keeps a jar file locked and this must be closed before the jar can be unloaded. The keys were inconsistent and changed several times (even between different build versions of the same JDK release) so the original clearSunJarFileFactoryCache code just seemed to stop working intermittently for people using windows. At some point someone gave up trying to understand what was wrong and wrote code to create temp versions of jar files. Redeploying an app would simply create 'new' temp jars leaving the old temp ones referenced and locked in the JarFileFactory. Over time the temp directory would fill up with temp jar files - These would only be deleted on a restart. My own redeployment tests highlighted this issue and I eventually dug in found the cause and fixed the ClassLoaderUtil.clearSunJarFileFactoryCache method - This was well over a year ago. I don't know if we actually need the whole temp jar code any more, but I left it in to be on the safe side (and also because it gets quite complicated and I didn't have time to fiddle). My redeployment tests consistently delete these temp jars for my own applications, which indicates the jar files are released. -- View this message in context: http://openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-0-0-beta-2-TomEE-1-0-0-beta-2-tp4274468p4285832.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
