Description of problem: When using rhq:file with a relative path for the destinationFile or destinationDir attribute, the relative path is resolved to an incorrect parent resulting in the file or directory being written or attempted to be written to the wrong place. For example, if deploying a bundle to an EAP profile base location with a relative path specified in the recipe such as: <rhq:file name="app.properties" destinationFile="../../conf/app.properties" replace="false"/> The expectation is the path will resolve to <JBOSS_HOME>/server/<JBOSS_PROFILE>/conf/app.properties. However, if <JBOSS_HOME>/server/<JBOSS_PROFILE>/deploy is a symbolic link to /var/local/jboss/eap/deploy, the relative path resolves to /var/local/jboss/eap/conf/app.properties. This results in the bundle's contents being written to the wrong location or failing to be deployed in the event that the resolved location is not writable by the user running the agent. Version-Release number of selected component (if applicable): 4.4.0.JON312GA How reproducible: Always Steps to Reproduce: 1. Create a physical directory outside of EAP 5.x profile to hold contents of deploy: mkdir -p /tmp/eap/apps 2. Move contents of EAP's <profile>/deploy directory to newly created location: mv ${JBOSS_HOME}/server/all/deploy /tmp/eap/apps/ 3. Create symbolic link in ${JBOSS_HOME}/server/all to /tmp/eap/apps/deploy: ln -s /tmp/eap/apps/deploy ${JBOSS_HOME}/server/all/deploy 4. Start EAP 5.x server 5. Start JBoss ON system 6. Add EAP server to inventory 7. Create bundle deployment using myBunlde.zip attachment 704238 [details] 8. Deploy bundle to EAP server deploy. * *Destination Name*: EAP Test Destination * *Resource Group*: EAP servers * *Base Location*: Profile Directory * *Deployment Directory*: deploy/myapp.deployment Actual results: app.properties was deployed to /tmp/eap/apps/conf/ Expected results: app.properties should be deployed to <JBOSS_HOME>/server/<JBOSS_PROFILE>/conf/ Additional info: When resolving paths, it seems we should be using getCanonicalPath() or a method that properly handles the relative . and .. path elements as they relate to the parent path and not the symbolic destination.
In Java 7 api, there is a class [1] doing exactly what we need, i.e. resolving the ".." and "." in the path, without resolving the symlinks. If we decide not to be backward compatible with Java 6, we can use it. [1] http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#normalize%28%29
In master (RHQ 4.9.0 codebase). commit a8472635e28dcdc053e5d3d4a700d5cd8c60e752 Author: Lukas Krejci <lkrejci> Date: Thu Jun 27 23:46:34 2013 +0200 [BZ 917765] - Symlinks in deploy dir no longer confuse relative file path if deployDir was: /opt/depls/target -> /opt/realdepls/realtarget (i.e. target was a symlink to realtarget) and a file was to be deployed to: ../conf/file a resulting path would be: opt/depls/target/../conf/file which would be resolved as: opt/realdepls/conf/file (i.e. the symlink would be resolved first and then the path would be normalized) This is not how people usually understand the paths and how they expect the bundle deployer to function. We therefore first manually normalize the path and only then obtain its absolute path to point to it during the deployment process. Notice that we no longer use the canonical paths anywhere in the deployer code.
As this is MODIFIED or ON_QA, setting milestone to ER1.
Created attachment 827335 [details] bundle-dest
verified in er5 with scenario Larry described - screen-shot attached