Package org.axonframework.messaging.eventhandling.tracing

Class TracingEventBus

java.lang.Object
org.axonframework.messaging.eventhandling.tracing.TracingEventBus
All Implemented Interfaces:
DescribableComponent, SubscribableEventSource, EventBus, EventSink
@Internal public final class TracingEventBus extends Object implements EventBus
Type-preserving tracing decorator for EventBus.

Composes a TracingEventSink for the publish path (so a TracingEventBus produces the exact same per-event publish span shape as a plain TracingEventSink) and passes subscribe straight through to the wrapped EventBus.

Type preservation matters because the component registry decorates by the slot's declared type (

invalid reference 
EventBus#getClass()
). Returning a plain TracingEventSink for an EventBus.class slot would fail DecoratedComponent's assignment check and abort configuration. Implementing EventBus directly mirrors InterceptingEventBus -- the in-tree precedent for type-preserving event-bus decoration.
Since:
5.3.0
Author:
Mateusz Nowak

  • Constructor Details

    • TracingEventBus

      public TracingEventBus(EventBus delegate, SpanFactory spanFactory)
      Initializes a tracing EventBus wrapping the given delegate, obtaining publish spans from the given spanFactory.
      Parameters:
      delegate - the event bus to delegate to
      spanFactory - the factory producing the tracing spans

  • Method Details

    • publish

      public CompletableFuture<Void> publish(@Nullable ProcessingContext context, List<? extends EventMessage> events)
      Description copied from interface: EventSink
      Publishes the given events within the given context, when present.

      When present, the post invocation phase is used to publish the events. As a consequence, the resulting CompletableFuture completes when the events are staged in that phase.

      When no ProcessingContext is provided, implementers of this interface may choose to create a ProcessingContext when necessary.

      Specified by:
      publish in interface EventSink
      Parameters:
      context - The processing context, if any, to publish the given events in.
      events - The events to publish in this sink.
      Returns:
      A CompletableFuture of Void. When this completes and a non-null context was given, this means the events have been successfully staged. When a null context was provided, successful completion of this future means the events were published.

    • subscribe

      public Registration subscribe(BiFunction<List<? extends EventMessage>,ProcessingContext,CompletableFuture<?>> eventsBatchConsumer)
      Description copied from interface: SubscribableEventSource
      Subscribe the given eventsBatchConsumer to this event source. When subscribed, it will receive all events published to this source since the subscription.

      If the given eventsBatchConsumer is already subscribed, nothing happens.

      Note on ProcessingContext: The ProcessingContext parameter passed to the consumer may be null. When null, it is the responsibility of the registered eventsBatchConsumer to create an appropriate ProcessingContext as needed for processing the events.

      Specified by:
      subscribe in interface SubscribableEventSource
      Parameters:
      eventsBatchConsumer - The event batches consumer to subscribe.
      Returns:
      A Registration handle to unsubscribe the eventsBatchConsumer. When unsubscribed, it will no longer receive events.

    • describeTo

      public void describeTo(ComponentDescriptor descriptor)
      Description copied from interface: DescribableComponent
      Describe the properties of this DescribableComponent with the given descriptor.

      Components should call the appropriate describeProperty methods on the descriptor to register their properties. The descriptor is responsible for determining how these properties are formatted and structured in the final output.

      Best Practices: As a general rule, all relevant fields of a DescribableComponent implementation should be described in this method. However, developers have discretion to include only the fields that make sense in the context. Not every field may be meaningful for description purposes, especially internal implementation details. Furthermore, components might want to expose different information based on their current state. The final decision on what properties to include lies with the person implementing the describeTo method, who should focus on providing information that is useful for understanding the component's configuration and state.

      Example implementation: 

       public void describeTo(ComponentDescriptor descriptor) {
     descriptor.describeProperty("name", this.name);
     descriptor.describeProperty("enabled", this.enabled);
     descriptor.describeProperty("configuration", this.configuration); // A nested component
     descriptor.describeProperty("handlers", this.eventHandlers);      // A collection
 }
      Specified by:
      describeTo in interface DescribableComponent
      Parameters:
      descriptor - The component descriptor to describe this DescribableComponentn its properties in.