Examples of EventBus

• com.google.common.eventbus.EventBus
  Dispatches events to listeners, and provides ways for listeners to register themselves.

  The EventBus allows publish-subscribe-style communication between components without requiring the components to explicitly register with one another (and thus be aware of each other). It is designed exclusively to replace traditional Java in-process event distribution using explicit registration. It is not a general-purpose publish-subscribe system, nor is it intended for interprocess communication.

  Receiving Events

  To receive events, an object should:

  1. Expose a public method, known as the event handler, which accepts a single argument of the type of event desired;
  2. Mark it with a {@link Subscribe} annotation;
  3. Pass itself to an EventBus instance's {@link #register(Object)} method.

  Posting Events

  To post an event, simply provide the event object to the {@link #post(Object)} method. The EventBus instance will determine the typeof event and route it to all registered listeners.

  Events are routed based on their type — an event will be delivered to any handler for any type to which the event is assignable. This includes implemented interfaces, all superclasses, and all interfaces implemented by superclasses.

  When {@code post} is called, all registered handlers for an event are runin sequence, so handlers should be reasonably quick. If an event may trigger an extended process (such as a database load), spawn a thread or queue it for later. (For a convenient way to do this, use an {@link AsyncEventBus}.)

  Handler Methods

  Event handler methods must accept only one argument: the event.

  Handlers should not, in general, throw. If they do, the EventBus will catch and log the exception. This is rarely the right solution for error handling and should not be relied upon; it is intended solely to help find problems during development.

  The EventBus guarantees that it will not call a handler method from multiple threads simultaneously, unless the method explicitly allows it by bearing the {@link AllowConcurrentEvents} annotation. If this annotation isnot present, handler methods need not worry about being reentrant, unless also called from outside the EventBus.

  Dead Events

  If an event is posted, but no registered handlers can accept it, it is considered "dead." To give the system a second chance to handle dead events, they are wrapped in an instance of {@link DeadEvent} and reposted.

  If a handler for a supertype of all events (such as Object) is registered, no event will ever be considered dead, and no DeadEvents will be generated. Accordingly, while DeadEvent extends {@link Object}, a handler registered to receive any Object will never receive a DeadEvent.

  This class is safe for concurrent use. @author Cliff Biffle @since Guava release 10

• com.google.gwt.event.shared.EventBus
  Extends {com.google.web.bindery.event.shared.EventBus} for legacy compatibility.
• com.google.web.bindery.event.shared.EventBus
  Dispatches {@link Event}s to interested parties. Eases decoupling by allowing objects to interact without having direct dependencies upon one another, and without requiring event sources to deal with maintaining handler lists. There will typically be one EventBus per application, broadcasting events that may be of general interest. @see SimpleEventBus @see ResettableEventBus @see com.google.web.bindery.event.shared.testing.CountingEventBus
• com.netflix.eventbus.spi.EventBus
  An event bus for in-process publish-subscribe communication between components. It aids in de-coupling publishers and subscribers and provides a simple way of publishing, filtering and listening to events.

  The various facets of the event bus is defined as follows:

  Publishers

  Publisher of events can publish the events in two modes as follows:

  • Unconditional: The event gets published irrespective of the fact whether there are any listeners or not. If there are no listeners, the event will be discarded.
  • Conditional: The event will be published iff there is atleast one listener for that event at the time publish is called. This style should be used only when creating the event object itself is costly, otherwise, the complexity is not worth the effort. In this case, the event creation is delayed using {@link EventCreator}. In case, a listener that showed interest in the event unregisters before receiving the same, it will not receive this event. On the other hand, if any new listener gets registered for this event after the initial check is made, it will receive this event, provided it gets registered before the event starts to get published. The interest of the listener for this event will only be based on the event type and not the event data as the data is not available initially. This essentially means that such an event may be filtered-out by the listener based on the event data when it actually receives the event.

  Events

  An event can be any arbitrary object and does not require any semantics.

  Subscribers

  Subscribers are the components that are interested in events generated by the publishers. A subscriber requests interest in certain events by providing a method with the annotation {@link Subscribe} and having just one argument, the event object itself.

  Event - Subscriber mapping

  Any subscriber method taking an event object of Class X as argument is expected to be interested in all events published corresponding to its superclasses and implemented interface (directly or via a superclass). In short if the invocation of {@link Class#isAssignableFrom(Class)} on the event object's class withthe subscriber class as argument returns true, then that subscriber is interested in the event.

  Dispatch mode

  All subscribers are async and isolated with any other listener i.e. a slow listener does not impact other listeners for the same event. At the same time, the event data is not copied for this isolation. The overhead of this isolation will just be the cost of storing references to these events in each listeners queue.

  A subscriber can indicate if it favors synchronous event consumption: This is just a backdoor and should be used with caution as then the consumption and filtering will happen in the publishing thread. Also, this behavior can be overridden if the property {@link SyncSubscribersGatekeeper#ALLOW_SYNC_SUBSCRIBERS} is set to false. In that case, theevents will be sent to the subscriber asynchronously. See {@link SyncSubscribersGatekeeper} for more details.

  There are multiple facets of this async dispatch mode which are described below:

  • Slow subscribers: In case the subscriber queue is full, the older events are rejected, one at a time and the event bus retries to offer the event to the subscriber, after each removal. This retry is capped at a default value {@link EventBus#CONSUMER_QUEUE_FULL_RETRY_MAX_DEFAULT} which can be overridden by a dynamic property:{@link EventBus#CONSUMER_QUEUE_FULL_RETRY_MAX_PROP_NAME}. If all the retries fail, the event is rejected.
  • Event batch: If the subscribers wish to process the events in batches, then they can annotate themselves with an appropriate {@link com.netflix.eventbus.spi.Subscribe.BatchingStrategy}. Care must be taken while batching as the rejections also happens in batch when the subscribers are slow.
  • Queue size: A subscriber can optionally define a queue size for the async dispatch using {@link com.netflix.eventbus.spi.Subscribe#queueSize()}. The default value for this queue size is {@link EventBus#CONSUMER_QUEUE_SIZE_DEFAULT} which can be changed via the fast property:{@link EventBus#CONSUMER_QUEUE_SIZE_DEFAULT_PROP_NAME}

  Event filtering

  Events can be filtered both before publishing and before receiving the same in the subscriber. Filtering at the subscriber end is done per subscriber. Filtering at the publisher side rejects the event.
  All filters for the event must return true for the event to be published/received Event filters can be expressed as a filter language as available under {@link com.netflix.eventbus.filter.lang}. Such a filter can then be converted into an {@link EventFilter} using {@link com.netflix.eventbus.filter.EventFilterCompiler}For relatively easy way of programmatic creation of filters, one can use the utility/factory class {@link com.netflix.eventbus.filter.EventFilters}.
  Subscriber level filtering is done in the consumer thread and not in the thread of the event publisher. This alleviates the overhead of event publishing that may be introduced by slow filter evaluation. However, it does have a side effect on the speed of event processing by the consumer and hence may increase the backlog for particular consumers. In any case, the impact of slow filters is isolated to the consumers and does not plague the event publishing that typically will happen in the client's request processing thread.

  Runtime event - subscriber binding

  Eventbus subscribers, by design, are statically tied to a particular type of object i.e. the class of the event it is interested in. This in most cases is beneficial and easy to use, however, in some cases (typically event agnostic, middlemen, which stores the event for later investigation), the event processing is much the same irrespective of the type of event it receives. In such a case, it will be an overhead (even if possible) to define a subscriber for each kind of event existing in the system. {@link DynamicSubscriber} is a way to achieve runtime binding of an eventto a subscriber. @author Nitesh Kant (nkant@netflix.com)
• com.ponysdk.core.event.EventBus
• cpw.mods.fml.common.eventhandler.EventBus
• de.kilobyte22.lib.event.EventBus
  Created with IntelliJ IDEA. User: Stephan Date: 07.03.13 Time: 18:41 @author Stephan Henrichs @copyright Copyright 2013 Stephan Henrichs
• net.customware.gwt.presenter.client.EventBus
• net.md_5.bungee.event.EventBus
• org.apache.cloudstack.framework.events.EventBus
  Interface to publish and subscribe to CloudStack events
• org.apache.shiro.event.EventBus
  guava-libraries.googlecode.com/git/javadoc/com/google/common/eventbus/EventBus.html">EventBus concept, although no code was viewed/copied/imported (even though Guava code is Apache 2.0 licensed and could have been used). @since 1.3
• org.apache.wicket.atmosphere.EventBus
  Broadcasts events to methods on components annotated with {@link Subscribe}. {@linkplain EventBus#post(Object) Posted} events are broadcasted to all components on activepages if they have a method annotated with {@link Subscribe}. To create and register an {@code EventBus}, put the following code in your application's init method:

   this.eventBus = new EventBus(this); 

  The {@code EventBus} will register itself in the application once instantiated. It might bepractical to keep a reference in the application, but you can always get it using {@link #get()}. @author papegaaij
• org.axonframework.eventhandling.EventBus
  Specification of the mechanism on which the Event Listeners can subscribe for events and event publishers can publish their events. The event bus dispatches events to all subscribed listeners.

  Implementations may or may not dispatch the events to event listeners in the dispatching thread. @author Allard Buijze @see EventListener @see SimpleEventBus @see ClusteringEventBus @since 0.1

• org.eurekastreams.web.client.events.EventBus
  The Event Bus.
• org.metawb.lib.EventBus
  EventBus implementation based on Lookup. This class is threadsafe. @author Ernie Rael {@literal }
• org.olat.core.util.event.EventBus

  Multiuser events

  This is the center distributing the multiuser events into the system.
  Classes implementing the {@link org.olat.core.util.event.GenericEventListener GenericEventListener} canregister for an event bound to a certain {@link org.olat.core.id.OLATResourceable}. A class having "news" concerning an OLATResourceable may fire {@link org.olat.core.util.event.MultiUserEvent Events} which are sent to alllisteners.
  NOTE: the listeners are put in a WeakHashMap, so they need to have another reference than just the event center. @author Felix Jost
• org.rstudio.studio.client.application.events.EventBus
• org.sonatype.sisu.goodies.eventbus.EventBus
• org.vaadin.spring.events.EventBus
  Interface defining an event bus. This event bus infrastructure complements the {@link org.springframework.context.ApplicationEventPublisher} in the following ways:

  • Events propagate from parent buses to children
  • Events are scoped

  There are three event scopes, and therefore three event bus types:

  1. {@link EventScope#APPLICATION} events are published to the entire application.
  2. {@link EventScope#SESSION} events are published to the current session.
  3. {@link EventScope#UI} events are published to the current UI.

  The event buses are chained in the following way:

  • Application events are propagated to the session event bus.
  • Session events are propagated to the UI event bus.

  Furthermore, {@link org.springframework.context.ApplicationEventPublisher} events are propagated to the application event bus (and further down the chain to the UI event bus).

  The primary {@code EventBus} implementation is always UI-scoped and can be injected into your UI classes like this: @Autowired EventBus myUIScopedEventBus; With this implementation, you can subscribe to and publish events of all scopes (see {@link #publish(EventScope,Object,Object)}).

  However, if you want to inject any of the other event buses, you have to use the {@link org.vaadin.spring.events.EventBusScope} qualifier. For example, the following code will inject the session event bus: @Autowired @EventBusScope(EventScope.SESSION) EventBus myUIScopedEventBus; @author Petter Holmström (petter@vaadin.com)

• org.vertx.java.core.eventbus.EventBus
  g">Tim Fox