I am sitting at the airport in Paris killing a couple of hours before my flight home.
As usually the wifi is not free of charge, so I decide to save the 10 euro / hour and write a blog entry instead.
The Fuse Community Day in Paris was a great event. I enjoyed meeting with people who I have been working together with online, but haven't had the chance to meet yet.
I was told the audience liked my Camel presentation despite I had to give it in English. Most of the speakers spoke in French.
Nevertheless its really great to meet end users and hear about the troubles with Camel and what they like etc. I was talking to Christian Mueller from Atos Worldline and he would like to be able to easier debug Camel routes.
I totally agree and said we have introduced the Debugger SPI in Camel 2.5, which he could leverage. Albeit the API was geared towards tooling such as the FuseSource Rider that James Strachan is working on.
So the story is that here at the airport I have made it very easy when using the Camel Test Kit to debug Camel routes by leveraging the Debugger API.
Given this route:
from("direct:start")
.to("mock:a")
.transform(body().prepend("Hello "))
.to("mock:b");
And having this unit test method:
public void testRoute() throws Exception {
// set mock expectations
getMockEndpoint("mock:a").expectedMessageCount(1);
getMockEndpoint("mock:b").expectedMessageCount(1);
// send a message
template.sendBody("direct:start", "World");
// assert mocks
assertMockEndpointsSatisfied();
}
Its now possible to single step debug the route using by adding the following code, in the top of the test method:
// you can debug camel routes easily as shown below:
debug(new BreakpointSupport() {
public void beforeProcess(Exchange exchange, Processor processor, ProcessorDefinition definition) {
// this method is invoked before we are about to enter the given processor
// from your Java editor you can just add a breakpoint in the code line below
log.info("Before " + definition + " with body " + exchange.getIn().getBody());
}
});
For example if we run the test the code above will log each step as shown:
[main] DebugJUnit4Test INFO Before To[mock:a] with body World
[main] DebugJUnit4Test INFO Before Transform[{prepend(body, Hello )}] with body World
[main] DebugJUnit4Test INFO Before To[mock:b] with body Hello World
So if you want to debug the route from your Java editor, all you have to do is to add a breakpoint in that code above and run in debug mode. Here is a screenshot from my editor showing this:
As you can see we hit the breakpoint in the Java editor and you can now inspect the Exchange.
The BreakpointSupport class has a number of methods you can override as callbacks at events.
- beforeProcess method is invoked before we enter a processor
- afterProcess method is invoked just after a processor
You can read more about this at the javadoc for the org.apache.camel.spi.Breakpoint interface.
I also though of instead beforeProcess and afterProcess as protected methods directly in the CamelTestSupport class allows you to easily debug by just overriding those method. Maybe we can have both solutions? I will start a discussion on the Camel mailing list about this.
Happy debugging!
As usually the wifi is not free of charge, so I decide to save the 10 euro / hour and write a blog entry instead.
The Fuse Community Day in Paris was a great event. I enjoyed meeting with people who I have been working together with online, but haven't had the chance to meet yet.
I was told the audience liked my Camel presentation despite I had to give it in English. Most of the speakers spoke in French.
Nevertheless its really great to meet end users and hear about the troubles with Camel and what they like etc. I was talking to Christian Mueller from Atos Worldline and he would like to be able to easier debug Camel routes.
I totally agree and said we have introduced the Debugger SPI in Camel 2.5, which he could leverage. Albeit the API was geared towards tooling such as the FuseSource Rider that James Strachan is working on.
So the story is that here at the airport I have made it very easy when using the Camel Test Kit to debug Camel routes by leveraging the Debugger API.
Given this route:
from("direct:start")
.to("mock:a")
.transform(body().prepend("Hello "))
.to("mock:b");
And having this unit test method:
public void testRoute() throws Exception {
// set mock expectations
getMockEndpoint("mock:a").expectedMessageCount(1);
getMockEndpoint("mock:b").expectedMessageCount(1);
// send a message
template.sendBody("direct:start", "World");
// assert mocks
assertMockEndpointsSatisfied();
}
Its now possible to single step debug the route using by adding the following code, in the top of the test method:
// you can debug camel routes easily as shown below:
debug(new BreakpointSupport() {
public void beforeProcess(Exchange exchange, Processor processor, ProcessorDefinition definition) {
// this method is invoked before we are about to enter the given processor
// from your Java editor you can just add a breakpoint in the code line below
log.info("Before " + definition + " with body " + exchange.getIn().getBody());
}
});
For example if we run the test the code above will log each step as shown:
[main] DebugJUnit4Test INFO Before To[mock:a] with body World
[main] DebugJUnit4Test INFO Before Transform[{prepend(body, Hello )}] with body World
[main] DebugJUnit4Test INFO Before To[mock:b] with body Hello World
So if you want to debug the route from your Java editor, all you have to do is to add a breakpoint in that code above and run in debug mode. Here is a screenshot from my editor showing this:
As you can see we hit the breakpoint in the Java editor and you can now inspect the Exchange.
The BreakpointSupport class has a number of methods you can override as callbacks at events.
- beforeProcess method is invoked before we enter a processor
- afterProcess method is invoked just after a processor
You can read more about this at the javadoc for the org.apache.camel.spi.Breakpoint interface.
I also though of instead beforeProcess and afterProcess as protected methods directly in the CamelTestSupport class allows you to easily debug by just overriding those method. Maybe we can have both solutions? I will start a discussion on the Camel mailing list about this.
Happy debugging!