Package org.axonframework.messaging.tracing.configuration

Class TracingConfigurationOrder

java.lang.Object
org.axonframework.messaging.tracing.configuration.TracingConfigurationOrder
@Internal public final class TracingConfigurationOrder extends Object
Ordering constants shared by the tracing modules' ConfigurationEnhancers and decorators.

This holder is Internal: it exists to keep the tracing modules' relative ordering in one place and is expected to be superseded by a framework-wide decorator-order constant holder. Applications ordering their own decorators relative to tracing should not depend on these values.

Since:
5.3.0
Author:
Mateusz Nowak

  • Field Details

    • TRACING_DECORATOR_ORDER

      public static final int TRACING_DECORATOR_ORDER
      Decorator order for all Tracing* component wrappers.

      Tracing decorators register at near-maximal order so they are applied last and end up as the outermost wrapper of every decorated component. This is a deliberate convention with two effects: (1) tracing spans cover the work of all inner decorators (interception, retries, security), so a span measures what the caller actually experiences; (2) any tracing wrapper is reliably the outermost layer of a registry-built component, so an instanceof Tracing* check is sufficient to detect an already-traced component (see TracingStateManager#register). Custom decorators on the same component types should use a lower order unless they deliberately need to observe tracing itself. The same value is used by every *TracingConfigurationEnhancer in the tracing modules.

      This sits on the opposite end of the scale from AxonFramework's own decorators, which deliberately decorate innermost -- e.g. org.axonframework.messaging.commandhandling.interception.InterceptingCommandBus#DECORATION_ORDER (Integer.MIN_VALUE + 100). The resulting stack is Tracing(...(Intercepting(Simple...))): dispatch and handler spans include interception time, and a message rejected by a dispatch interceptor still produces a span.

      See Also:

    • PROVIDER_ENHANCER_ORDER

      public static final int PROVIDER_ENHANCER_ORDER
      Enhancer order for the *SpanAttributesProviderConfigurationEnhancer classes contributing the built-in SpanAttributesProvider implementations.

      These run at the default order, before the defaults enhancers. Correctness does not depend on this: contribution is decorator-based and only applied when the SpanFactory consuming the registry is constructed -- after the enhance phase has completed.

      See Also:

    • TRACING_DEFAULTS_ENHANCER_ORDER

      public static final int TRACING_DEFAULTS_ENHANCER_ORDER
      Enhancer order for tracing defaults enhancers -- the ones registering default components via ComponentRegistry.registerIfNotPresent(java.lang.Class<C>, org.axonframework.common.configuration.ComponentBuilder<? extends C>) (the
      invalid reference 
      SpanAttributesProviderRegistry
      , the *TracingSettings defaults).

      Runs last, mirroring AxonFramework's MessagingConfigurationDefaults#ENHANCER_ORDER, so that user-supplied and property-translated registrations (typically contributed at the default order) take precedence over these defaults.

      See Also: