Created attachment 493018 [details] exception Description of problem: Globally uncaught exception adding new scheduled operation Version-Release number of selected component (if applicable): 04/18/2011 How reproducible: 100% Steps to Reproduce: 1. Inventory/Resources/localhost/JBossAS Servers 2. Operations tab, click New Button 3. Observe exception Actual results: see attached screenshot. Number format exception Expected results: a new scheduled operation Additional info:
Basically this is about scheduling start|stop|restart operations on the RHQ JBoss AS instance itself. It's been allowed for awhile and understandably after you shut down the RHQ instance we get various types of 'globally uncaught exception's. Why hasn't this been addressed before or rather why have we continually allowed this?
This is currently how the RHQ code works and it is the JBoss AS* plugin that exposes all the operations for discovered AS servers. The fact that the RHQ server is itself a JBoss AS server that can be stop|start|restarted is currently acceptable behavior within the RHQ management model. It is up to the administrator to effectively protect these specific JBoss AS servers from being operated upon by excluding said servers from other 'non-RHQ' EAP/JBoss instances. The current plugin model could be enhanced in the following way to make this distinction clearer: <mazz> spinder: even if you could, that's not the way we would solve this. it violates the plugin architecture to start adding code in the core (which I also include the UI and CLI in) that says, "if this resource is a super-special resource, do this super-special code that is reserved only for it" <mazz> that kind of thing still needs to be driven by plugin metadata <mazz> in addition, its actually a feature that coould be useful to other plugins <mazz> so putting it in the plugin design opens it up for others to be able to use, rather than use add some one-off hard-coding feature to support only RHQ-specific resources <mazz> IMO, I would either close that BZ or change it to a RFE to expand it to say: <mazz> "allow child types to disable parent features - such as allowing a child type to disable one or more parent operations" <mazz> that obviously is not trivial to implement, but its better than spewing hardcoded, "if" statements in the core to handle special cases This is a non-trivial amount of work with wider implications. Changing to and RFE, setting back to NEW and lowering the priority.