For an example, when the EAR/WAR Stop operation in the AS5 plugin fails gracefully, the following is displayed in the GUI: java.lang.Exception: Operation 'start' on ResourceType[id=0, category=Service, name=EJB3 JAR, plugin=JBossAS5] Resource with key [vfszip:/C:/opt/jboss-eap-5.0.0-SNAPSHOT/server/all/deploy/EjbStatefulCounter.jar/] The resource is already started at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:278) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Instead, just the message should be displayed, i.e.: Operation 'start' on ResourceType[id=0, category=Service, name=EJB3 JAR, plugin=JBossAS5] Resource with key [vfszip:/C:/opt/jboss-eap-5.0.0-SNAPSHOT/server/all/deploy/EjbStatefulCounter.jar/] The resource is already started This is occurring because of a limitation in the OperationServerService.API: void operationFailed(String jobId, Configuration result, ExceptionPackage error, long invocationTime, long completionTime); Note, the method provides no nice way to return a simple error message. You must either wrap the error message in an Exception (which is what the PC does in OperationInvocation.run()) or stick it in the result Configuration, which typically won't work because the operation result's ConfigurationDefinition might not provide a String property that can be used (e.g. the result type could even be void). One way to fix this would be to add a new method to OperationServerService: void operationFailed(String jobId, Configuration result, String errorMessage, long invocationTime, long completionTime); or even just:: void operationFailed(String jobId, String errorMessage, long invocationTime, long completionTime);
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2363
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
I think the methods we have today are sufficient. If a plugin developers wants to catch this particular case (a resource is already in the started state and when the start operation is called), then they should return "success" as a result. In other words, catch the stack trace and call operationSuccess(...) instead of operationFailed(...). This will be done on a plugin-by-plugin basis, and as you pointed out needs to be done for the AS5 plugin.
I think this is no longer an issue.