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
>
>
This archive was generated by hypermail 2.0.0 : Wed May 12 2010 - 06:38:50 UTC