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
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
We renamed the operation and added an additional parameter. I'm guessing the rename counts as deletion of the old definition. 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rename definitely counts as a removal of the op and an addition of a new one (since we have no idea that this "new" name is actually the old one that you renamed)
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. 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
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
Am I correct in understanding that an enhancement request for this would reduce fragility and regressions? If so, I am +1 on this ....
----- Original Message ----- 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" 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
There was a good bit of refactoring done as part of the work to add support for deleting plugins. I just checked and it looks like we should now support deleting operation defs. Take a look at OperationMetadataManagerBeanTest.removeOperationDefFromTypeThatPreviouslyDefinedOperationDef.
- John
On 6/23/11 12:52 PM, Ian Springer wrote:
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users
rhq-users@lists.stg.fedorahosted.org