The standard JBI management message does not have extensibility elements, which could have been used to add the "instance name". This would help the end user know which instance threw what exception. The management runtime had to use a workaround to insert the "instance name" into the composite response.
Before I go into the details of what the work around is, a few details on how a facade MBean for target=cluster creates a composite response. When a management operation is invoked on an instances JSR 208 management Mbean the operation will respond with a management message in case the task was a success ( albeit partial ) or throw an exception, with the exception message being a management message. For example if we have a cluster with two instances and a service assembly deployment operation succeeds on one instance and fails on another, then the composite response to the client would be a partial deploy success message with a warning indicating that deploy failed on the second instance. This is how the facade MBean builds this composite response :
The management response from both the instances are processed and a new management message is created with new elements as follows :
There is one shortcoming in the above: the response is ambiguous. It is difficult to tell which task status message / exception info belongs to which instance.
To over come this we decided to add "marker" task status messages and exception-info to the message which would bear the instance name. The msg-loc-info within these would be as follows :
msg-loc-info/loc-token=JBI_INSTANCE_NAME
msg-loc-info/loc-message="instance name"
An instance "marker" status message / exception info will preceed the task status message / exception info specific to the instance in a framework component task result.
An example XML management message with the "markers" is here
An example of the ant task output after making this change is :
Test Case :
Deploy a service assembly targeted to two components to a cluster.
The cluster has two instances. One of the test component throws an exception on service unit deploy.
So the end result is that the service assembly is partially deployed to both instances, and the net
response is a SUCCESS w/ WARNING message. Marker "instance" task status messages are added to the
framework result and the component task result. The ant task output is as follows :
Service assembly deployment partially succeeded. [
WARNING:(JBI_INSTANCE_NAME)cluster1-instance1
(JBIMA0404)Deployment of service assembly esbadmin00089-sa succeeded partially; some service units failed to deploy.
(JBI_INSTANCE_NAME)cluster1-instance2
(JBIMA0404)Deployment of service assembly esbadmin00089-sa succeeded partially; some service units failed to deploy.
Component: manage-binding-1
WARNING:(JBI_INSTANCE_NAME)cluster1-instance1
(JBIWHOOPS)SU deploy failed
(JBI_INSTANCE_NAME)cluster1-instance2
(JBIWHOOPS)SU deploy failed
This is work in progress, the client code will format this message to seggregate the instance specific responses further.
This would currently break tests for cluster targets, the reference files for the broken tests need to be updated, since this is work in progress and the common client will be further formatting the messages, it is recommended that to fix the tests only once after the common client changes are done.