Using Event Bus in NetBeans

Apache NetBeans Wiki Index

Note: These pages are being reviewed.

Dne Monday 26 November 2007 17:37:48 Rob Ratcliff napsal(a):
> For the bus we developed, we could subscribe by a specific type, for all
> subclasses of a type or for certain message header attributes of an
> event. We also had a bus per "session" (the GUI could display multiple
> sessions/workspaces using tabs -- equivalent to a JMS topic)  so that
> only events related to that session would be delivered. And, like I
> mentioned earlier, there was support to register as a "GUI" listener or
> a "business" listener so that events would automatically be delivered in
> the correct thread to avoid EDT lockup and rendering issues.
> I'd be interested in hearing what you and others think about these types
> of capabilities and how they compare to the NetBeans paradigms.

I’ve been thinking about this for a while and I believe that there is event bus like system in NetBeans. It is Utilities.actionsGlobalContext()

We have our event bus and it is accessible via Utilities.actionsGlobalContext(). Indeed it may not be perfect, but it plays exactly the role described in the presentation. Menu, Toolbar, etc. listen on it, while somebody else updates it.

Indeed, there could be some improvements. We do not support merging of events or network access, but if one really cares, there is a way to plug into the system. All one needs to do is to implement ContextGlobalProvider One sample implelemention is in openide/windows and second in

I’ve heard a complain that…​

> This is a central listener, not an event bus

  1. however this boils down to a question: How do you envision an event bus? It is a place to contain events or objects that somehow appear in the system. It allows anyone to selectively listen on what is happening in the bus

So in fact event bus is a central listener. Just like Utilities.actionsGlobalContext().

Indeed it could be improved. Is there anyone who would like to contribute in improving our actionsGlobalContext? If so, what should be done?

Hi Jaroslav,

I think it'd be useful to define exactly what an event bus is (like you
mentioned),  what use cases it supports and how NetBeans supports these
use cases currently and how it might support these in the future.

I used an EventBus approach in my last project  for receiving
asynchronous data events from the Network (such as position updates,
network status events) and internal events such as service status
(network disconnected) and other state change events such as "sensor
network reconfigured"...essentially when it made more sense to use a hub
and spoke communication model rather than a point-to-point.  There could
be multiple instances of the EventBus, which used a  EDT type of model
(dispatcher thread/queue) and supported subscriptions by type (any event
derived from a base class)  or property of the header.

Since the "Lookup Library" allows you to uncouple senders from receivers, and allows receivers to be notified of changes, I consider it as a small event bus.

I consider "local lookups" as a small event bus, where you can listen to different "event topics". In the previous case, it would probably be enough to dedicate on Lookup for the network events and create various types holding enough information about the events. The you could add/remove/change the content of the lookup and deliver events about such changes.

The instances
could be looked up globally or injected into a given component. It
supported "business" and "GUI"  subscriptions to automatically deliver
the event in the correct thread. If I did it again,  I'm  thinking I'd
use a JMS style API that supported a Hibernate style OQL subscription.
(I have some more details here:

The EventBus talk given at JavaOne 2006 had some great use case examples:

These frameworks provide some other use cases and API examples:



Bradlee Johnson's ReflectionBus

Jasper-Potts - Why Spaghetti Is Not Tasty: Architecting Full-Scale
Swing Apps, 2007 JavaOne Conference, TS-3316

(Also see the JMS API and the OMG COS Notification Service API.)

I don't have much time to spend a lot of time coding on the side right
now, but I'd be happy to help define requirements and use cases if that
would be useful to you.