[jboss-dev-forums] [JBoss Microcontainer Development] - AbstractStructureDeployer.getRelativePath fails to handle unrelated paths

Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] created the discussion "AbstractStructureDeployer.getRelativePath fails to handle unrelated paths" To view the discussion, visit: http://community.jboss.org/message/561697#561697 -------------------------------------------------------------- For the weld-int https://community.jboss.org/message/561400 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 https://jira.jboss.org/browse/JBDEPLOY-265 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)          while(!childPath.startsWith(tempFile.getPathName()))          {             relativePath.append("/.."); // for every level we need to go up in the file system             tempFile = tempFile.getParent();          }          relativePath.append(childPath.substring(tempFile.getPathName().length()));          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? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/561697#561697] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]