geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <>
Subject Re: Offline Deployer leaving behind temporary files
Date Wed, 23 Jan 2008 18:43:22 GMT
I have found the culprit.  It is the URLs that we use to read content from
an archive, for e.g., META-INF/application.xml from an ear file.  The
deployer is creating a JarFile and closing the JarFile after the deployment
operation is completed.  JarFile.close() closes all the InputStreams
obtained from the JarFile and releases any locks.

For e.g., in EARConfigBuilder.getEarPlan(), we have code like the following:

URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile,
specDD = DeploymentUtil.readAll(applicationXmlUrl);

After this code is executed the earFile is locked until the JVM terminates.
If you replace the above with something similar to

        InputStream inp = earFile.getInputStream(earFile.getJarEntry
        BufferedReader br = new BufferedReader(new InputStreamReader(inp));
        String line;
        while((line = br.readLine()) != null) {
            specDD += line;

the earFile is no longer locked once earFile.close() is called and can be
deleted anytime.  This is what is observed on Win XP.


On Jan 23, 2008 8:52 PM, Kevan Miller <> wrote:

> On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
> > 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.
> I wouldn't trust that comment. Dain's commit was addressing this very
> problem (at least within the server runtime:
> You need to check to see what type of ClassLoader is being used. If
> it's not JarFileClassLoader, then we understand the problem. If it is
> JarFileClassLoader, then maybe we aren't calling destroy. If we doing
> all of these things, then obviously I'm wrong again... ;-)
> --kevan

View raw message