Feature has been introduced with commit(s) that you can see in the apposite section.
The following is a brief riepilogue Lifecycle of QMan resource (let's suppose for simplicity that only one managed resource, a queue, exists on Qpid) :
- Qpid starts;
- QMan starts;
- A content indication message is sent to QMan. This message referes to a queue instance.
- Message is received by QMan but it doesn't know what is a "queue", its definition so therefore the incoming data is stored in raw (byte ) format and a schema request is sent to Qpid for "queue" class.
- Qpid receives the schema requests and produces the corresponding schema response;
- QMan receives the schema response, builds the queue class definition, uses the previously stored raw data for create and populate the MBean instance corresponding to queue object. A JMX Notification is sent to all registered listeners.
- The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the creation of the queue instance.
- The incoming notification provides the objectname (the JMX identifier) of the created object so the WSDM adapter uses the MBEan Info in order to introspect the queue object instance and therefore create the WS-Resource including its WSDL and capability class.
Now the queue exists under the following perspectives :
- on Qpid broker as a manageable object instance;
- on QMan JMX core as an MBean
- on QMan WS-DM as a WS-Resource (WSDL + capability classses)
Let's suppose that, for some reason, the queue is deleted (undeclared) from Qpid. What is happening on QMan side? Here it is :
- A content indication message is sent by the broker to QMan with a "timeObjectWasDeleted" property valorized with the corresponding value;
- QMan detects that the instance has been removed and as a conseguence of that the corresponding MBean is unregistered from MBean Server; A JMX notification is sent to all registered listeners.
- The WS-DM Adapter previously registered itself as an interested listener for that kind of events so it is notified about the deletion of the queue instance.
- The incoming notification provides the objectname of the mbean that has been removed. The WS-DM Adapter, which is using that objectname as resource identifier, uses that for find the WS-Resource and destroy it.
At this point the queue resource has been deleted from all the perspective.