Bug 716229 - RFE: Consider enhancements to facilitate plugin development and reduce fragility
RFE: Consider enhancements to facilitate plugin development and reduce fragility
Status: NEW
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2011-06-23 13:32 EDT by Mike Foley
Modified: 2011-10-06 15:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2011-06-23 13:32:29 EDT
Description of problem:  Consider enhancements to facilitate plugin development and reduce fragility by having metrics and operations having a name which never
changes and also a lookup key,

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

From: "Ian Springer" <ian.springer@redhat.com>
To: rhq-users@lists.fedorahosted.org
Sent: Thursday, June 23, 2011 12:52:25 PM
Subject: Re: cannot update plugin operation

Yes, I know exactly what you're talking about. I've hit this same issue
in the jboss-as-5 plugin when the names of various profile service
managed components, operations, and properties were still in flux on the
AS side.

I think ideally, metrics and operations should have a name which never
changes and also a lookup key, which is the string that would be used by
the plugin for looking up the underlying metrics or operations on the
managed resource.

For example:

<metric name="dowDetails"
         displayName="DOW Industrial Components details" ... />

Of course, we'd have to make sure to add this in a backwards compatible way. I think essentially, the new "lookupKey" attribute would have to be optional. I'd also love to deprecate the metric element's "property" attribute and replace it with a "name" attribute. I never liked the name "property". It's inconsistent with all the other types of plugin descriptor elements, and "name" also makes more sense because it maps to the "name" field on the MeasurementDefinition entity.

Feel free to file an enhancement request for this. If we see interest from other users in the feature, it's something we will consider adding.

-- Ian

On 06/21/2011 10:06 PM, Bala Nair wrote:
> That is a possibility.  However, there are 2 issues our plugin
> developers have - first is that they aren't the ones developing the
> managed resource and therefore have to match the operation names in the
> plugin to the jmx bean operation names in the managed resource.  If that
> changes we see this error.  Second, we're adding processing instructions
> to the name so we can inject transformations into the data collection
> mechanism.  We couldn't figure out any other way to do this since the
> plugin xml schema is pretty strict.  For example we use a structure like
> the following to transform jmx complex data types to json strings in our
> resource component handler's getValues() and invokeOperation() methods.
> <!-- retrieve complex data as json string for jquery table -->
> <metric property="TabularData.djia"
>                  displayName="DOW Industrial Components details"
>                  dataType="trait"
>                  defaultOn="true"
>                  displayType="summary"
>                  defaultInterval="300000"
>                  description="Retrieves stock quotes on the DOW 30
> components"/>
> <!--
>            Define any operations your custom MBean exposes and that you
> want to invoke via RHQ.
>         -->
> <operation name="TabularData.getQuotes"
>                     displayName="Retrieve stock quotes"
>                     description="Retrieve some random stock quotes.">
> <parameters>
> <c:simple-property name="symbols" description="stock ticker symbols
> separated by '+'"/>
> </parameters>
> <results>
> <c:simple-property name="operationResult" type="string"/>
> </results>
> </operation>
> On 6/21/11 5:39 PM, Ian Springer wrote:
>> On 06/21/2011 04:21 PM, Bala Nair wrote:
>>> We renamed the operation and added an additional parameter.  I'm
>>> guessing the rename counts as deletion of the old definition.
>> Yep, that's correct.
>> An operation def has both a name and a displayName. The name is the one
>> that's used by the metadata update code and by the plugin API. The
>> display name is what you see in the GUI. Considering that, would it be
>> an option for you to keep the name the same as it was, and instead
>> change the displayName?
>> -- Ian
>>> We're
>>> running RHQ v3.  I haven't checked bugzilla yet.
>>> On 6/21/11 2:06 PM, John Mazzitelli wrote:
>>>> What change did you make to your plugin metadata? did you remove an
>>>> operation definition?
>>>> What RHQ version?
>>>> Did you check bugzilla? I'm not sure what happens if an operation is
>>>> removed. I would have thought that would have been a use-case we
>>>> covered, but perhaps not? I'm not sure.
>>>> On 06/21/2011 12:26 PM, Bala Nair wrote:
>>>>> without first deleting operation history. I get the following error in
>>>>> the server log:
>>>>> 2011-06-21 09:25:43,988 INFO
>>>>> [org.rhq.enterprise.server.core.plugin.ProductPluginDeployer] Deploying
>>>>> [1] new or updated agent plugins: [quoteserver]
>>>>> 2011-06-21 09:25:45,007 WARN [org.hibernate.util.JDBCExceptionReporter]
>>>>> SQL Error: 0, SQLState: 23503
>>>>> 2011-06-21 09:25:45,007 ERROR [org.hibernate.util.JDBCExceptionReporter]
>>>>> Batch entry 0 delete from RHQ_OPERATION_DEF where ID='10301' was
>>>>> aborted. Call getNextException to see the cause.
>>>>> 2011-06-21 09:25:45,007 WARN [org.hibernate.util.JDBCExceptionReporter]
>>>>> SQL Error: 0, SQLState: 23503
>>>>> 2011-06-21 09:25:45,007 ERROR [org.hibernate.util.JDBCExceptionReporter]
>>>>> ERROR: update or delete on table "rhq_operation_def" violates foreign
>>>>> key constraint "rhq_operation_history_operation_def_id_fkey" on table
>>>>> "rhq_operation_history"
>>>>> Detail: Key (id)=(10301) is still referenced from table
>>>>> "rhq_operation_history".
>>>>> This makes updating plugins somewhat problematic. We are bundling our
>>>>> service specific plugins into rpms for deployment and this behavior
>>>>> would break updates via rpm. Is there any way around this?
>>>>> Bala Nair
>>>>> SeaChange International

rhq-users mailing list

rhq-users mailing list

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