Community
Participate
Working Groups
It is possible to extend the DiagramEventBroker right now, but it is broken... DiagramEventBrokerThreadSafe is package protected. Anyone extending DiagramEventBroker would therefore break the threading behavior. Perhaps this functionality should be folded into DiagramEventBroker? DiagramEventBroker#getInterestedNotificationListeners is final. This is one of the main reasons to override DiagramEventBroker in order to broadcast an event to a set of derived semantic criteria without adding explicit listeners.
I'll be happy to address this in the form of a patch... Assign to me if desired.
fireNotification needs to be "protected" rather than "private" as well...
Created attachment 57565 [details] Patch for DiagramEventBroker Extensibility This patch opens up extensibility for the DiagramEventBroker. The DiagramEventBrokerThreadSafe has been eliminated and replaced by a ResourceSetHandler mechanism that allows internal clients to register a different handler. This makes it possible for external clients to register a different DiagramEventBroker without eliminating the functionality of the DiagramEventBrokerThreadSafe.
Note: there is also a possible race condition to do with when the overriden DiagramEventBroker gets installed. Currently it is reliant on plug-in loading which creates an opening where the default broker will be active for a duration. Investigation needs to be done whether the current mechanism (api to register) needs to be replaced with a Service or extension point mechanism instead.
Agreed that this work can be done in the 2.0 stream.
After a discussion with Steve and Gelb ; we agreed on a set of changes that need to be done to the diagram event broker i'm going to do these changes on stages 1- allowing clients to extended the diagram event broker by removing the final key word from some methods, and making some methods protected instead of final 2- Allowing sub classes of the diagram event broker to forward events on deletd objects to listeners 3- trying to get ride of the DiagramEventBrokerThreadSafe 4- handling the some issues with the Diagram event broker factory
stage 1 and 2 are done
stage 4 is delivered
Since GMF 2.0 M6 was released April 5, 2007, doing a bulk move of all open Bugzillas currently on M6 to 2.0 M7. Owners will need to access if the issue really is targetted for 2.0 M7.
I think this Bugzilla is complete?
(In reply to comment #10) > I think this Bugzilla is complete? No it is not
The only remaining piece is to get ride of the Diagram event broker thread safe since it will require clients to copy code to get there diagram event broker working otherwise they will have threading problems
Client has copied code from GMF into his application.
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
