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: 1. 2. 3. Actual results: Expected results: Additional info: From: "Ian Springer" <ian.springer> To: rhq-users.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" lookupKey="TabularData.djia" 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.org https://fedorahosted.org/mailman/listinfo/rhq-users _______________________________________________ rhq-users mailing list rhq-users.org https://fedorahosted.org/mailman/listinfo/rhq-users