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

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?