Description of problem: If a JBoss EAP server installation can be reached by its physical path and a symbolic link, it can result in multiple resources being discovered and potentially added to resource even though they represent the same server. Version-Release number of selected component (if applicable): 4.4.0.JON312GA How reproducible: Always Steps to Reproduce: 1. Install JBoss EAP 5.2 default server. 2. Create symbolic link to EAP bin directory: TEST_ROOT="${PWD}" mkdir -p "${TEST_ROOT}/opt" ln -s "${JBOSS_HOME}" "${TEST_ROOT}/opt/jboss" 3. Set JBOSS_HOME to its real location: JBOSS_HOME="${JBOSS_HOME}" 4. Start EAP default using its real path: "${JBOSS_HOME}/bin/run.sh" -c default -b 0.0.0.0 & 5. Start JBoss ON system. 6. Import EAP default server into inventory. Note that its resource key will be the real path. 7. Stop EAP server. 8. Start the EAP server using a complete path to the symbolic link: "${TEST_ROOT}/opt/jboss/bin/run.sh" -c default -b 0.0.0.0 & 9. Wait for EAP server to finish starting. 10. From platform resource, execute discovery scan. Actual results: A second EAP server is discovered with a resource key that resolves to the symbolic link path. Expected results: Discovery should have detected an existing resource as the same resource key should be generated. Additional info: This appears to be a direct result of how the plug-in resolves the JBOSS_HOME path for use when resolving the various directories including the configuration directory ($JBOSS_HOME/server/$JBOSS_CONF). As the configuration path is used as the resource key, this will result in a newly created resource. Although we do not want to break existing inventory by simply changing the discovered key to resolve symbolic links to their actual paths, we need to figure out a way to reconcile the resources.
Fixed in master commit 326ce595e6a83773c377bfb3865618878be8bae9 Author: Thomas Segismont <tsegismo> Date: Fri Feb 7 22:23:57 2014 +0100 The BZ was filed for EAP5 but the same problem occurs with EAP6 Use canonical path of configDir for resource key in EAP5 Use canonical path of hostConfigFile for resource key in EAP6 Old resource keys will be upgraded to preserve existing inventories JBossInstanceInfo: removed usage of deprecated methods and made code easier to read. *Note on testing EAP5* The BZ report does not mention it but you won't be able to reproduce the problem if agent runs as root or as the same user as the managed server (this is because of the org.rhq.plugins.jbossas5.helper.JBossInstanceInfo.getHomeDir implementation).
release/jon3.2.x commit 9fabc56323a945dcc26fe1453860cf3a247376fd Author: Thomas Segismont <tsegismo> Date: Fri Feb 7 22:23:57 2014 +0100 Cherry-Pick master 326ce595e6a83773c377bfb3865618878be8bae9 Conflicts: modules/plugins/jboss-as-7/src/main/java/org/rhq/modules/plugins/jbossas7/BaseProcessDiscovery.java Signed-off-by: Jay Shaughnessy <jshaughn>
Additional commit in master commit dec128372c115130f0c2f06d5b32fa8357533d95 Author: Thomas Segismont <tsegismo> Date: Tue Feb 11 10:54:05 2014 +0100 EAP6 resource upgrade code was screwed by a wrong substring start index...
Cherry-picked over to release/jon3.2.x commit b678265cd4f521f4aa0b09d1b7884db166e7b203 Author: Thomas Segismont <tsegismo> Date: Tue Feb 11 10:54:05 2014 +0100
Moving to ON_QA as available for testing in the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=336752 Note: the installed version is still JON 3.2.0.GA by design and this represents part of the payload for JON 3.2.1 also known as cumulative patch 1 for 3.2.0.GA. How this will be delivered to customers is still being discussed.
Verified on JON 3.2.1 DR01 build (Build Number :c758688:4c03150) Followed the steps and verified by running the agent as user other than root user.
JON 3.2.1 released week of 5/5/2014