This issue was original patched in JBoss ON 3.1.2 but was not included in 3.3 due to the work being done in Bug 1224093 which would make this change unnecessary. However, since then it has been decided that the work in BZ 1224093 is too risky considering its return so late in the maintenance cycle.

Therefore, we now need to pull the changes from the 3.1.2 patch tracked in BZ 1203469 into the 3.3 maintenance stream for inclusion in an upcoming release.



+++ This bug was initially created as a clone of Bug #1203469 +++

Description of problem:
The JBoss EAP plug-in is not able to discover JBoss EAP 6 servers that define a product slot that is not already known. This means that as products evolve, the plug-in is no longer able to identify them even as a generic AS/WildFly instance.

In the case of JBoss ON 3.1.2, the JBoss EAP 6 plug-in was released prior to the release of Fuse Service Works. Although the plug-in has not been tested and is not supported for use with FSW, the underlying container is JBoss EAP 6. The expectation is that the JBoss EAP 6 portion of the server is discovered in the same manner as a community AS 7 or WildFly instance.

Version-Release number of selected component (if applicable):
3.1.2

How reproducible:
Always

Steps to Reproduce:
1.  Install, configure, and start JBoss ON 3.1.2 system.
2.  Install configure, and start FSW 6 standalone server:

        JBOSS_HOME=/opt/jboss/fsw/jboss-fsw-6
        "${JBOSS_HOME}"/bin/standalone.sh -b 0.0.0.0 &

3.  From JBoss ON inventory, execute server discovery scan.

Actual results:
Discovery of server fails and agent.log includes the following exception:

    ERROR [ResourceDiscoveryComponent.invoker.daemon-4] (rhq.modules.plugins.jbossas7.StandaloneASDiscovery)- Discovery of a JBossAS7 Standalone Server Resource failed for process: pid=[2382], name=[java], ppid=[2314].
    java.lang.RuntimeException: Failed to determine product type for JBoss product installed at [/opt/jboss/fsw/jboss-fsw-6].
        at org.rhq.modules.plugins.jbossas7.JBossProductType.determineJBossProductTypeViaHomeDirName(JBossProductType.java:133)
        at org.rhq.modules.plugins.jbossas7.JBossProductType.determineJBossProductType(JBossProductType.java:66)
        at org.rhq.modules.plugins.jbossas7.BaseProcessDiscovery.buildResourceDetails(BaseProcessDiscovery.java:193)
        at org.rhq.modules.plugins.jbossas7.StandaloneASDiscovery.buildResourceDetails(StandaloneASDiscovery.java:84)
        at org.rhq.modules.plugins.jbossas7.BaseProcessDiscovery.discoverResources(BaseProcessDiscovery.java:136)
        at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:293)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)


Expected results:
Resource should be discovered as AS or EAP instance without any error being reported.

Additional info:
The primary reason for this failure is that the FSW installation has a product.conf file which has a product slot of soa. This product slot is not defined in this version of the plug-in because SOA only shipped based on the EAP 5 plug-in at the time of the JBoss ON 3.1.2 release.

Because the product.conf exists and the slot can not be determined, we fall back to attempting to identify the product from the path. It is unclear why this is done as the path will most likely not contain any portion of the product name considering that in a real installation, jboss-eap-... is not the path used but rather jboss-server-01 or jboss-servers or something specific to the user's business rules. In the case of JBoss ON 3.1.2, even if the example/default path used by the distribution of FSW 6 is used, the value is still unknown by the plug-in. This results in the product type identification throwing a RuntimeException that causes discovery to abort.

It seems that if the product can not be determined from the product.conf (whether it exists or not) and falling back to the installation directory doesn't find a matching product, that we would either fall back to AS or perhaps  EAP.

--- Additional comment from Larry O'Leary on 2015-03-18 19:39:51 EDT ---



--- Additional comment from Larry O'Leary on 2015-03-19 17:48:55 EDT ---

This is a new version of the proposed patch that limits the "fallback to AS" behavior to a manual add only.

--- Additional comment from Larry O'Leary on 2015-03-19 19:24:45 EDT ---

In regards to the patch proposed in comment 2, it is to fix the following error which causes manual add to fail:

    ERROR [WorkerThread#0[172.17.0.58:34906]] (rhq.core.pc.inventory.InventoryManager)- Manual add failed for resource of type [JBossAS7 Standalone Server] and parent resource id [10001]
    java.lang.reflect.UndeclaredThrowableException
        at com.sun.proxy.$Proxy111.discoverResource(Unknown Source)
        at org.rhq.core.pc.inventory.InventoryManager.discoverResource(InventoryManager.java:362)
        at org.rhq.core.pc.inventory.InventoryManager.manuallyAddResource(InventoryManager.java:738)
        ...
    Caused by: java.lang.Exception: Discovery component invocation failed.
        at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:297)
        ...
    Caused by: java.lang.IllegalArgumentException: No product type with product-name 'Red Hat JBoss Fuse Service Works' is known.
        at org.rhq.modules.plugins.jbossas7.JBossProductType.getValueByProductName(JBossProductType.java:76)
        at org.rhq.modules.plugins.jbossas7.BaseProcessDiscovery$ProductInfo.getFromRemote(BaseProcessDiscovery.java:607)
        at org.rhq.modules.plugins.jbossas7.BaseProcessDiscovery.discoverResource(BaseProcessDiscovery.java:443)
        ...