Details
-
Enhancement
-
Resolution: Done
-
Major
-
None
-
None
Description
When the ModelController attempts to find the OperationStepHandler for a given operation + address, it needs to handle failure more intelligently. Instead of providing a one-size fits all exception, it should try to determine why the OSH couldn't be found and tailor the exception accordingly. Specifically, clarify whether the problem is the address is invalid or the operation name is invalid, and if it's the address that's invalid, clarify the point in the resource tree where the address goes wrong.
For example, a user attempting to administer a server that has already been shut down gets this fairly useless exception:
Error loading VM metrics
Unexpected HTTP response: 500
Request
{
"operation" => "composite",
"address" => [],
"steps" => [
,
,
,
{ "address" => [ ("host" => "master"), ("server" => "server-one"), ("core-service" => "platform-mbean"), ("type" => "operating-system") ], "operation" => "read-resource", "include-runtime" => true } ]
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => "JBAS010850: No handler for operation read-resource at address [
(\"host\" => \"master\"),
(\"server\" => \"server-one\"),
(\"core-service\" => \"platform-mbean\"),
(\"type\" => \"memory\")
]",
"rolled-back" => true
}
The reality is no resource exists at address /host=master/server=server-one. The failure message should emphasize this fact.