Bug 1015665

Layered products provide their product names etc and we should not rely on loging inside the as7 plugin to determine if they are right.

org.rhq.modules.plugins.jbossas7.BaseServerComponent#validateServerAttributes checks for a few things - especially to warn if e.g. a user has had a SOA6 server in inventory, shuts it down and then starts an EAP that has the same port(s) and the user finds half of the objects in inventory all of a sudden being down.

At this point we should relax the check for a "valid" product.

There is at least one other place in the code where org.rhq.modules.plugins.jbossas7.JBossProductType#getValueByProductName
is called.
Perhaps we should not have that throw exceptions when the product type is not found, but "UNKNOWN" and let the layered plugins sort that out on their own.
Not sure if the callback is also called for manual add or not though".


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

Description of problem:
 I am getting an exception in agent log file when I import SOA6 instance

Version-Release number of selected component (if applicable):
JON 3.2.ER2 + SOA6.1.ER3

How reproducible: always


Steps to Reproduce:
1. start soa6 server
2. discover it
3. import it

Actual results:
ERROR [ResourceContainer.invoker.daemon-22] (rhq.modules.plugins.jbossas7.BaseServerComponent)- Failed to validate product type for ResourceType[id=0, name=JBossAS7 Standalone Server, plugin=JBossAS7, category=Server] [hostConfig: /home/hudson/jboss-soa6/standalone0/configuration/standalone.xml].
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:104)
        at org.rhq.modules.plugins.jbossas7.BaseServerComponent.validateServerAttributes(BaseServerComponent.java:211)
        at org.rhq.modules.plugins.jbossas7.BaseServerComponent.getAvailabilityNow(BaseServerComponent.java:154)
        at org.rhq.modules.plugins.jbossas7.BaseServerComponent.getAvailability(BaseServerComponent.java:139)
        at org.rhq.modules.plugins.jbossas7.BaseServerComponent.start(BaseServerComponent.java:101)

Expected results:


Additional info: this exception might be harmless, 'cause I can manage/monitor/configure/deploy with such server as usual

--- Additional comment from Simeon Pinder on 2013-10-04 08:59:31 EDT ---

@Libor, this looks like a problem in the latest Fuse plugin.  For your SOA testing you could remove or disable the Fuse plugin and this will go away, but we need to raise this as a concern with the Fuse team.  They can now be solved on the plugin side using Discovery Callbacks: https://docs.jboss.org/author/display/RHQ/Discovery+Callbacks

- Moving out of SOA plugin.
- I'm putting assign/needinfo on Dhiraj Bokde so that he can take a look at this.

Curious things to note:
- Why is the AS7 plugin even involved here? IIRC they are still JMX based but I'll have to look into that further.

--- Additional comment from Mike Foley on 2013-10-04 10:27:50 EDT ---

per jon triage, assigning to soa team

--- Additional comment from JBoss Product and Program Management on 2013-10-04 10:31:15 EDT ---

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Dhiraj Bokde on 2013-10-04 12:37:32 EDT ---

Fuse plugins do not support JBoss Fuse Service Works (JFSW), which looks like a customized version of an AS7 server. 

This is not a Fuse plugin problem since they won't discover JFSW, and as the error is being thrown by the AS7 plugin that's where it should be fixed. 

Thanks,
Dhiraj.

--- Additional comment from Simeon Pinder on 2013-10-04 12:44:23 EDT ---

@Dhiraj, sorry about that.  The conversation about the right fix for this is still going on and we've since agreed that the issue is in the As7 plugin.  I was about to update the BZ again before you responded.

--- Additional comment from Dhiraj Bokde on 2013-10-04 12:46:42 EDT ---

@Simeon, no worries. I could see why it would be confusing. For a product that uses our group's name 'Fuse', Fuse engineering had no idea what this product was until a week ago. :)

--- Additional comment from  on 2013-10-04 13:00:35 EDT ---


Please see https://bugzilla.redhat.com/show_bug.cgi?id=998023

--- Additional comment from Mike Foley on 2013-10-04 13:14:18 EDT ---

kicked back from soa team to jon team. this issue surfaced before and may have been related to ..

https://bugzilla.redhat.com/show_bug.cgi?id=998023

soa6 plugin qe (varun/viet) to retest with JON 3.2 ER3.

--- Additional comment from Heiko W. Rupp on 2013-10-04 14:40:58 EDT ---

The product name has been changed so that above warning should no longer show up.

master 9adf1e4


-    SOA("SOA-P", "JBoss SOA-P 6", "Red Hat JBoss Fuse Service Works", "SOAP"),
+    SOA("SOA-P", "JBoss SOA-P 6", "Red Hat JBoss Fuse Service Works", "Red Hat JBoss Fuse Service Works"),


For the future we need to remove that bogus check and let the layered plugins provide / decide the product name here.