shashank created CAMEL-26688:
--------------------------------
Summary: camel-core - step listener SPI for the exchange sanitizer
Key: CAMEL-26688
URL: https://issues.apache.org/jira/browse/CAMEL-26688
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: shashank
Assignee: shashank
Step 1 of the order of work of the exchange sanitizer design (CAMEL-26630,
design document in apache/camel#29296).
*What it adds*
* {{org.apache.camel.spi.StepListener}} in camel-api: a listener that observes
each call of the processor of a step of a route: {{onStepCall}} (the call
starts; returns a state for the call), {{onStepReturn}}, {{onStepThrow}} and
{{onStepCallback}} (each time the callback of the call is called, before it
continues the exchange). All methods have an empty default. A listener only
observes; many can be installed, separate from the one {{StepHook}}.
* {{ExtendedCamelContext.addStepListener}}, {{removeStepListener}} and
{{getStepListeners}}, as default methods (the pattern of {{setStepHook}}).
* The Javadoc of the contracts the routing engine relies on, which is not
written down today: the callback of {{AsyncProcessor.process(exchange,
callback)}} is called exactly once, {{process}} does not throw (it sets the
exception and calls the callback), and the {{doneSync}} of the callback is the
value {{process}} returns (except for a processor that hands its callback to
the reactive executor, as the channel of each step does); and for
{{Synchronization}}, that the commit of a consumer runs {{onComplete}} or
{{onFailure}} once, where it is held at the end, and moves only by a handover.
* When at least one step listener is installed when a route is created,
{{DefaultChannel}} adds one small wrapper after the {{InterceptStrategy}} loop,
around what the loop returns. The error handler of the step calls it for each
attempt (also each redelivery), and the channel calls it for a step without
such an error handler. The strategies still get the processor of the step as
their target, and the {{StepHook}} is asked before the wrapper, so a step the
hook fails is not a call the listeners see.
With no listener installed the routes are built exactly as today: no wrapper,
no check per step.
A listener that throws cannot change the routing: each call of a listener is
caught and logged at WARN once per listener, the processor is called whatever
{{onStepCall}} did, the real callback is called in a {{finally}}, and what the
processor throws is thrown on unchanged.
Not in this issue: the on completion listener, the {{camel-sanitizer}} module
and its rules, the JUnit extension and the dev console (later steps of
CAMEL-26630). A JMH benchmark in camel-performance-tests will check, before the
change is merged, that a step without a listener costs the same as before.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
