[jira] Commented: (GERONIMO-3208) In-place deployment fails when renaming file

["Aman Nanner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GERONIMO-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501690 ] 

Aman Nanner commented on GERONIMO-3208:
---------------------------------------

Ok, I figured out what the problem is.  The problem is with {{org.apache.geronimo.deployment.util.NestedJarFile}}.  A bug was introduced in revision 520533.  Specifically, examine the following code:

{code}
        	if(targetEntry instanceof UnpackedJarEntry) {
        		//unpacked nested module inside unpacked ear
        		File targetFile = ((UnpackedJarEntry) targetEntry).getFile();
        		baseJar = new UnpackedJarFile(targetFile);
                        basePath = "";
{code}

You can see that the basePath is set to an empty String.  However, this causes a problem when the {{isPacked()}} method is called from an external caller:

{code}
    public boolean isPacked() {
        if (isClosed) {
            throw new IllegalStateException("NestedJarFile is closed");
        }
        return basePath.length() == 0;
    }
{code}

This method determines if the JAR is packed by checking that there is a non-empty base path.  However, as of revision 520533, it appears that an "unpacked" JAR can have an empty "basepath" if it has a non-null "baseJar".

This causes a problem during in-place deployment, because of the following code in {{org.apache.geronimo.deployment.InPlaceResourceContext}}:

{code}
    public void addInclude(URI targetPath, ZipFile zipFile, ZipEntry zipEntry) throws IOException {
        if (zipFile instanceof NestedJarFile) {
            NestedJarFile nestedJarFile = (NestedJarFile) zipFile;
            if (nestedJarFile.isPacked()) {
                zipFilesToExpand.add(zipFile);
            }
        }
        
        configuration.addToClassPath(targetPath.toString());
    }
{code}

Unpacked JAR files will be interpreted as "packed" because of the above bug.

> In-place deployment fails when renaming file
> --------------------------------------------
>
>                 Key: GERONIMO-3208
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3208
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: deployment
>    Affects Versions: 2.0-M6
>         Environment: Windows XP SP2
>            Reporter: Aman Nanner
>             Fix For: 2.0-M6
>
>         Attachments: inplace-deployment-fails.ear.zip
>
>
> I am using the latest SNAPSHOT of Geronimo.
> I was trying to deploy my custom application with Geronimo using "in-place" deployment, but it would fail with a ZipException and an "Access denied" message at the following line:
> {code}
> System Thread [RMI TCP Connection(189)-192.168.12.66] (Suspended (breakpoint at line 127 in InPlaceResourceContext))	
> 	InPlaceResourceContext.flush() line: 127	
> 	EARContext(DeploymentContext).flush() line: 428	
> 	TomcatModuleBuilder(AbstractWebModuleBuilder).installModule(JarFile, EARContext, Module, Collection, ConfigurationStore, Collection) line: 312	
> 	AbstractWebModuleBuilder$$FastClassByCGLIB$$8523248f.invoke(int, Object, Object[]) line: not available	
> {code}
> So I tried creating a small EAR file for testing purposes, and deployment of it also failed but at a different point:
> {code}
>      [java] Error: Unable to distribute testing.ear: Problem closing war context
>      [java] Cannot rename file
>      [java] D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war
>      [java] to
>      [java] D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war.saved
> {code}
> This failed at line 121 in the {{InPlaceResourceContext}} class.  I've attached the sample EAR file that was causing me this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.