0 Replies Latest reply on Sep 13, 2010 11:42 PM by Flavia Rainone

    AbstractStructureDeployer.getRelativePath fails to handle unrelated paths

    Flavia Rainone Master


      For the weld-int tests I've been working on, I ended up finding a problem involving the case where a classpath entry in the manifest file generates a faulty classpath entry in the deployment context.


      In the test I'm performing, I deploy a file named weld-translator.jar that lacks a class. The class needed for the deployment to be successful is in weld-translator-lib.jar, located in $JBOSS_HOME/server/all (or anywhere you name in the filesystem, except in the deploy dir). This jar is referenced by a relative classpath entry in the weld-translator.jar manifest file.


      The problem is noticed when WeldFilesDeployer checks on whether the file weld-translator-lib.jar/META-INF/beans.xml exists. The exists method returns false when it should return true.


      What I discovered is that:

      1. VFSUtils.addManifestLocations      transforms the relative Classpath entry found in the manifest file      (../weld-translator-lib.jar) into an absolute path      ($JBOSS_HOME/server/all/weld-translator-lib.jar)
      2. AbstractStructureDeployer.getRelativePath      was supposed to revert it to a relative path, but fails to do so,      instead, it returns the absolute path      $JBOSS_HOME/server/all/weld-translator/lib.jar
      3. VFSStructureBuilder      assumes that the path is relative, and, for that reason, it assembles the following classpath with the goal of getting the absolute classpath: $JBOSS_HOME/server/all/deploy/weld-translator.jar/$JBOSS_HOME/server/all/weld-translator-lib.jar
      4. WeldFilesDeployers uses the path generated in the step above to append the suffix META-INF/beans.xml. That's why it fails to find it.


      I created a Jira to fix AbstractStructureDeployer.getRelativePath, and I wrote a fix for it as well.


               // Assuming that child and parent don't have a parent -> child relationship
               // but instead, have a common path with different suffixes
               VirtualFile tempFile = parent;
               StringBuilder relativePath = new StringBuilder();
               // find the prefix that child shares with parent (in tempFile)
                  relativePath.append("/.."); // for every level we need to go up in the file system 
                  tempFile = tempFile.getParent();
               childPath = relativePath.toString().substring(1);


      Ales, can you please let me know if everything is ok? I couldn't find tests for getRelativePath... should I write one for JBDEPLOY-265? Where should that test be added to?