ExecutionSubscriber
SPI that allows the execution of individual interactions (action invocations or property edits) to be subscribed to.
The typical use case is to facilitate coarse-grained messaging for system-to-system interactions, that is from an Apache Causeway application to some other system. This could be done using a pub/sub bus such asApache ActiveMQwithApache Camel.
Only actions/properties annotated for publishing (using Action#executionPublishing() or Property#executionPublishing() are published.
API
interface ExecutionSubscriber {
void onExecution(Execution<?, ?> execution) (1)
}| 1 | onExecution(Execution)
Callback to notify that an interaction (an action invocation or property edit, as represented by Execution ) has completed. |
Members
onExecution(Execution)
Callback to notify that an interaction (an action invocation or property edit, as represented by Execution ) has completed.
This callback method is called by the framework immediately after the interaction (not at the end of the transaction, unlike some of the other subscribers).
Most implementations are expected to use Execution#getDto() to create a serializable XML representation of the execution. The easiest way to do this is using InteractionDtoUtils#newInteractionDto(Execution) .
Implementation
The framework allows multiple implementations of this service to be registered; all will be called.
This is an SPI, but the framework provides a simple implementation, o.a.c.applib.services.publishing.log.ExecutionLogger, that just logs events as they are received.
It can be configured using:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Properties> ... </Properties>
<Appenders> ... </Appenders>
<Loggers>
...
<logger
name="org.apache.causeway.applib.services.publishing.log.ExecutionLogger"
level="debug"/>
...
</Loggers>
</Configuration>See the log4j2-spring.xml file in simpleapp for the omitted detail.
Wrapper Factory
If the WrapperFactory is used to call other objects then the metrics are captured for each sub-execution.
Related Services
See also:
-
the InteractionContext is used to obtain the Interaction from which the member executions are published.
-
the EntityChangesSubscriber is used to obtain the set of objects modified within the interaction
-
the MetricsService is used to obtain the objects that are loaded throughout the transaction; this info is used in order to instantiate the EntityChanges object passed through to the EntityChangesSubscriber.
-
The services provided by this module combine very well with the CommandSubscriber and with EntityPropertyChangeSubscriber.
The Command captures the cause of an interaction (an action was invoked, a property was edited), while the ExecutionSubscriber captures the effect of that interaction in terms of events, while the EntityPropertyChangeSubscriber captures the effect of the interaction in terms of changed state.
All of these services collaborate implicitly by way of the HasInteractionId interface.
In contrast:
-
The EventBusService differs from the ExecutionSubscriber in that the former is intended for fine-grained publish/subscribe for object-to-object interactions within an Apache Causeway domain object model.
The event propagation is strictly in-memory, and there are no restrictions on the object acting as the event; it need not be serializable, for example.