Yeah, removing all listeners will have effect on the local
notifications.
In this situation I would install the JMSBridge programmatically as
well instead of via Modeler. Then you have a hold of the instance to
remove and maybe can even check for the JMS presence prior to adding
the listener.
On the other hand I have no objections to adding a "getListeners"
method to 3.1/3.0.1, internally scanning through all the invocation
queues.
Andrus
On May 12, 2010, at 3:29 AM, Andrew Lindesay wrote:
Hello;
I would like to programatically disable "change notification" (JMS)
if the JMS broker is not configured for the deployment.
DataDomain dd = ...
DataRowStore drs = dd.getSharedSnapshotCache();
drs
.getEventManager().removeAllListeners(drs.getSnapshotEventSubject());
It occurs to me that this could be dangerous if there are other
listeners on the event manager for the DataRowStore -- is that ever
likely to happen or will those listeners always be change
notification listeners?
There does not seem to be an API for getting the listeners so I
presume I can't work through them removing instances of JMSBridge?
Thanks for any help.
cheers.
___
Andrew Lindesay
www.silvereye.co.nz
