On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves
a lock on the module file preventing rebuilds
// to address this we use a gross hack and copy the file
to a temporary directory
// the lock on the file will prevent that being deleted
properly until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile("geronimo-deployer",
".tmpdir");
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the "preventing rebuilds" part in the above? It
is followed by code that creates a temporary copy of the module
archive that should be cleaned up by DeployerReaper which does not
delete these files in case of offline deployment. In online
deployment also, the files may be left behind if the DeployerReaper
does not get a chance to run after the files are added to
pendingDeletionIndex. Incase of offline deployment DeployerReaper
does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline
deployment, but the files won't just go away. I am wondering if the
reason this is introduced in the first place is applicable to 2.x.
If not, we can get rid of this code.
Hi Vamsi,
Well, the fact that the files are locked indicates a problem, I think.
Can you tell who's reading the files? I thought we would be using
org.apache.geronimo.kernel.classloader.JarFileClassLoader and would
thus avoid the Windows file locking problem.
Hmm, perhaps we're not calling JarFileClassLoader.destroy()? This
should free up the file locks.
--kevan
