Package org.axonframework.extension.spring.config

Class SagaProcessorDefinition

java.lang.Object
org.axonframework.extension.spring.config.SagaProcessorDefinition
public final class SagaProcessorDefinition extends Object
Configures the event processor carrying one or more Axon Framework 4 @Saga types, declared as a Spring bean.

Sagas do not take part in the PooledStreamingEventProcessorModule.Customization channel, because that is how cross-cutting Axon Framework 5 infrastructure such as dead-lettering attaches itself to every processor, and a Saga should not silently acquire behavior Axon Framework 4 never gave it. This is the replacement for that channel, scoped to Sagas: a type only a Saga's own configuration declares, so no Axon Framework 5 extension can arrive through it.

An EventProcessorDefinition configures a Saga's processor too, but it answers two questions a Saga has already settled. It has to state which handlers it assigns, which for a Saga is nobody, and it fixes the processor's mode, so a definition written only to change a batch size also overrules a mode=subscribing property. This type states neither.

A pooled streaming and a subscribing processor expose different configuration, so a customization touching mode-specific settings says which mode it was written against: SagaProcessorDefinition.Selector.whenPooledStreaming(UnaryOperator) or SagaProcessorDefinition.Selector.whenSubscribing(UnaryOperator). Naming the mode does not select it. A Saga's mode comes from axon.eventhandling.processors.<name>.mode or a matching EventProcessorDefinition, and a definition written for the other mode is skipped, with a warning, so a customization never quietly does nothing. Letting an adjustment switch the processor's kind would be a far larger change than the adjustment itself, since it decides whether there is a token store, whether there are segments, and whether a second application instance starts a duplicate Saga.

SagaProcessorDefinition.Selector.customized(UnaryOperator) covers the settings both modes share and never mentions a mode.

Example usage: 


 @Bean
 SagaProcessorDefinition replayIntoOrderSaga() {
     return SagaProcessorDefinition.forSaga(OrderSaga.class)
                                   .whenPooledStreaming(config -> config.initialToken(
                                           source -> source.firstToken(null)
                                   ));
 }

 @Bean
 SagaProcessorDefinition orderSagaEventSource(SubscribableEventSource source) {
     return SagaProcessorDefinition.forSaga(OrderSaga.class)
                                   .whenSubscribing(config -> config.eventSource(source));
 }

Applied after everything else that configures the processor: the Saga defaults, the axon.eventhandling.processors.<name>.* properties, and a matching EventProcessorDefinition. Several definitions matching one processor are applied in Spring bean order.

Since:
5.4.0
Author:
Mateusz Nowak

  • Method Details

    • forSaga

      public static SagaProcessorDefinition.Selector forSaga(Class<?> sagaType)
      Starts a definition for the processor carrying the given sagaType, wherever that Saga was assigned.

      The Saga type selects the processor; it does not narrow the customization to that one Saga. A processor is the unit of configuration, so when sagaType shares its processor with other Sagas, the customization applies to all of them. That case is logged, since naming one Saga and configuring several is worth noticing; prefer forProcessor(String) there, which says so in the code.

      Preferred over forProcessor(String) for a Saga on its own processor: it follows the Saga if the processor is renamed with a @Namespace or assigned by an EventProcessorDefinition selector, and it does not go stale when the Saga type is renamed.

      Parameters:
      sagaType - the Saga type whose processor to configure
      Returns:
      the next step, naming the processor mode and the customization to apply

    • forProcessor

      public static SagaProcessorDefinition.Selector forProcessor(String processorName)
      Starts a definition for the Saga processor named processorName.

      Use this to configure a processor shared by several Sagas in one place. To configure the processor of a single Saga, prefer forSaga(Class), which needs no knowledge of how the name was derived.

      Parameters:
      processorName - the name of the Saga processor to configure
      Returns:
      the next step, naming the processor mode and the customization to apply