Description of problem: If a JBoss AS instance has had its data directory relocated or renamed, the JBoss AS plug-in fails to determine a valid Naming Provider URL (JNP URL) for the plug-in configuration for the newly imported resource. Version-Release number of selected component (if applicable): JON 2.4.1 How reproducible: Always Steps to Reproduce: 1. Install a fresh EAP server 2. Start it an alternate location for its data directory: ./run.sh -c default -b 0.0.0.0 -Djboss.server.data.dir=/tmp/data/eap/default 3. Discover and import the new EAP instance Actual results: The AS resource is imported but it is marked DOWN and the JNP URL is not set under <resource> -> Inventory >> Connection. The agent also logs the following warning: WARN [ResourceDiscoveryComponent.invoker.daemon-847] (org.rhq.plugins.jbossas5.ApplicationServerDiscoveryComponent)- Failed to read JNP URL from '/opt/jboss/eap/jboss-eap-5.1/jboss-as/server/default/data/jnp-service.url'. Expected results: The AS resource is imported and the JNP URL is correct. The value should be read from /tmp/data/eap/default/jnp-service.url Additional info: This issue is cause by the assumption that the data directory is fixed or the presence is required by AS. Instead, this value is determined based on configuration of the AS instance itself and if not explicitly set, will default to ${jboss.server.home.dir}/data. The plug-in should not assume the default and instead use the value provided by the system property ${jboss.server.data.dir} and if not set, fall-back to the current behavior.
Can this be fixed for JON 3.2 release?
I have cloned this bug to the JBoss ON product bug tracker as bug 911692.
I committed a fix to this in master: 8130e34 I see the JNP URL is discovered now (I see it in the plugin config in the UI) but my initial test showed the server is still DOWN. I don't know if this is because some other part of the plugin code expects the data directory to be in the default location or if it was a local problem on my box only (I was having port conflicts and the problem might be due to that). I'm still testing.
I corrected my runtime issue (it was a local problem) and I tested the fix for this BZ. It looks good.