Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056517 - InvalidPluginConfigurationException in agent log - product type is [Portal], was Portal Platform - with JPP 6.1.1.ER01
Summary: InvalidPluginConfigurationException in agent log - product type is [Portal], ...
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JPP
Version: JON 3.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Martin Vecera
Depends On:
Blocks: 1058233
TreeView+ depends on / blocked
Reported: 2014-01-22 11:16 UTC by mgottval
Modified: 2014-09-15 00:06 UTC (History)
7 users (show)

Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1058233 (view as bug list)
Last Closed: 2014-02-07 15:35:24 UTC
Type: Bug

Attachments (Terms of Use)

Description mgottval 2014-01-22 11:16:50 UTC
I installed JON 3.2.CR1 - copy all the *.jar plugins from jon-plugin-pack-jpp-3.2.0.CR1 into JON-server/plugins, install and start the server. Downloaded and start rhq-agent. JPP 6.1.1.ER01-redhat-1 is running and is discovered by JON-server, I imported it from discovery queue.

In the rhq-agent log, there appears an InvalidPluginConfigurationException:

Unable to connect to managed resource of type [JBossAS7 Standalone Server] using the specified connection properties.
org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Failed to start component for resource Resource[id=10078, uuid=fd5c9b3e-276e-4e78-92fb-0653a521676b, type={JBossAS7}JBossAS7 Standalone Server, key=hostConfig: /home/mgottval/NotBackedUp/GateIn/jboss-portal-6.1/standalone/configuration/standalone.xml, name=JPP (, parent=localhost.localdomain, version=JPP 6.1.1.ER01].
	at org.rhq.core.pc.inventory.InventoryManager.activateResource(
	at org.rhq.core.pc.inventory.InventoryManager.updatePluginConfiguration(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at org.rhq.enterprise.communications.command.impl.remotepojo.server.RemotePojoInvocationCommandService.execute(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(

Caused by: org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: Failed to validate product type for ResourceType[id=0, name=JBossAS7 Standalone Server, plugin=JBossAS7, category=Server] [hostConfig: /home/mgottval/NotBackedUp/GateIn/jboss-portal-6.1/standalone/configuration/standalone.xml]
	at org.rhq.modules.plugins.jbossas7.BaseServerComponent.validateServerAttributes(
	at org.rhq.modules.plugins.jbossas7.BaseServerComponent.getAvailabilityNow(
	at org.rhq.modules.plugins.jbossas7.BaseServerComponent.getAvailability(
Caused by: org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: The original product type discovered for this server was Portal Platform, but the server is now reporting its product type is [Portal]
	at org.rhq.modules.plugins.jbossas7.BaseServerComponent.validateServerAttributes(

Comment 1 Thomas Segismont 2014-01-22 15:40:30 UTC
This is because AS7 plugin found the "jpp" slot in the product.conf file, and so expects the server "product-name" attribute to be "Portal Platform" (see )

To work around product name changes, you need to use a new feature introduced in "Bug 1015665 - Remove bogus product name check."

You need to create a ResourceDiscoveryCallback in the JPP plugin and update the plugin configuration in org.rhq.core.pluginapi.inventory.ResourceDiscoveryCallback#discoveredResources

In your case, set the plugin config "expectedRuntimeProductName" attribute to "Portal" if JPP version is above X, X being the version which introduced the product name change.

Comment 2 Nick Scavelli 2014-01-22 17:13:37 UTC
I'm not following entirely (it's been awhile since I look at this stuff). Is this all achievable via config, or do I need to introduce a class ? Our plugin is here

If it's only config, could you just edit it out on github to give me an idea of what you're talking about ?

Comment 3 Thomas Segismont 2014-01-22 17:26:16 UTC
No unfortunately it's not only configuration, you need to write a discovery callback where you will overwrite the value of the plugin config "expectedRuntimeProductName" attribute for JPP servers above version X.

There is a discovery callback in the RHQ Server plugin. Have a look at it to see how it works:

Comment 4 Nick Scavelli 2014-01-23 14:33:05 UTC
So how will this plugin work for older versions of JON that do not have this feature ?

Comment 5 Thomas Segismont 2014-01-23 15:01:28 UTC
Plugins are certified for a particular version of JON, so you shouldn't deploy the new plugin to older JON installs.

Comment 6 Nick Scavelli 2014-01-23 18:59:10 UTC
This is what I got atm:

However I don't think it's working, I had QA test it since they had the environment setup. I'll probably try and get this setup locally tomorrow so I can debug, but if you see any issues with what I've added, please let me know

Comment 7 Thomas Segismont 2014-01-24 08:52:10 UTC
The last commit looks good. Make sure things happen in this order:
1. the new plugin version was uploaded and scanned by the server
2. the agent(s) was(were) restarted or the "Update all plugins" operation was executed
3. the standalone server resource is removed from inventory an re-discovered

Comment 8 Nick Scavelli 2014-01-28 23:00:33 UTC
So I can confirm as QE has said, that this exception is thrown on a fresh install of JON discovering JPP 6.1.1 for the first time using the 6.1.0 plugin, but not during import. It's actually thrown when you fix the connection settings of the server. You can see full stacktrace here (in which it's actually an INFO level log statement)

It's quite strange, but this happens when you FIX the credentials. Meaning I can change the password to something that doesn't work, change it back, restart agent and this exception will be thrown again. This doesn't seem to effect the way the resource data is gathered from the agent.

So even though the plugin seems to work fine, I have updated it to include the discovery callback. The only thing with this is that it is relying on the DiscoveredResourceDetails.getResourceName() to start with string "JPP" I'm not sure if there's a better way to know for sure if it's a portal server (rhq server looks for in the process info). However if we change wherever the JPP string is coming from in the future, it seems worse case scenario there's an INFO log with a stacktrace...

Comment 9 Tomas Kyjovsky 2014-01-29 18:21:43 UTC
I can see the same behavior as Nick. The exception is thrown when I fix the connection parameters (credentials) for the imported JPP resource for 6.1.1.ER1. I didn't need to restart the agent to see this exception.

I tried two variants of this upgrade scenario: 6.1.0.CR02 --> 6.1.0.CR03 --> 6.1.1.ER01 (all with jon-server, agent and plugin-pack 3.2.0.GA):

A) When I kept the upgraded JPP server in the same folder there were no exceptions, even for 6.1.1.ER01 (since the credentials for the JPP resource were already set from 6.1.0). The exception was only thrown after the mentioned credentials change&fix.

The JPP resource kept being updated from the latest upgraded JPP server.

B) When I installed each subsequent version in a separate folder from the previous one there was a new JPP resource in the discovery queue each time. After import an additional resource was added with the same name (JPP) and parameters. When setting correct credentials for the newly added JPP resource for 6.1.0.CR03 there was exception in agent log such as:

org.rhq.core.pluginapi.inventory.InvalidPluginConfigurationException: The server listening on has base dir [/home/tkyjovsk/workspace/jpp61cr3/installs/jboss-jpp-6.1/standalone], but the base dir we expected was [/home/tkyjovsk/workspace/jpp61cr2/installs/jboss-jpp-6.1/standalone]. Perhaps the management hostname or port has been changed for the server with base dir [/home/tkyjovsk/workspace/jpp61cr2/installs/jboss-jpp-6.1/standalone].

When setting correct credentials for newly added JPP resource for 6.1.1.ER01 I got the exception.

After some time all of the JPP resources were shown as available and all were getting statistics updates from the running instance.

Note You need to log in before you can comment on or make changes to this bug.