...
The breakpoint can be invoked in 2 kind of styles in Camel:
- processing based
- event based
The processing is based on a before
and after
callback when the Exchange is being routed and thus a Processor is invoked.
...
The condition can be invoked in 2 kind of styles in Camel:
- processing based
- event based
Where there is a match
method for each style.
...
In the Java editor the debugger is capable of single stepping when a breakpoint is hit. The idea in Camel is that you want to single step an Exchange so you can step through how its routed and follow it from the 3rd party tooling.
Tip | ||
---|---|---|
| ||
The Debugger only allows one active breakpoint during single step, which means that if you try to activate a 2nd single step, then it will disregarded. In this case the |
The Debugger
has API for single stepping. For example to single step the first message arrived in Camel you can do
...
Code Block |
---|
public void testDebug() throws Exception { // we only want to single step the beer route context.getDebugger().addSingleStepBreakpoint(breakpoint, beerCondition); getMockEndpoint("mock:result").expectedBodiesReceived("Hello World", "Carlsberg"); template.sendBody("direct:start", "Hello World"); template.sendBody("direct:beer", "Carlsberg"); assertMockEndpointsSatisfied(); assertEquals(2, logs.size()); assertEquals("Single stepping at log:beer with body: Carlsberg", logs.get(0)); assertEquals("Single stepping at mock:result with body: Carlsberg", logs.get(1)); } |
Notes
- The single step feature should only allow one active at any time. So if there is already a single step message in process other messages should be disregarded from debugging
- Should other breakpoints be active during single step? In case you have another breakpoint somewhere which may get triggered?
- Should we add a fluent builder syntax for sugar, so its easier to use common conditions?
...