Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should be
reading this file. I guess it is the same with other builders as well. The
JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on windows,
since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released when the
jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
++Vamsi
On Jan 23, 2008 7:48 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> 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
>
