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&...]