THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Debugger
Available as of Camel 2.6
Camel Debugger is much related to Tracer, in fact they are sisters. Debugger is a enhanced tracer with Camel supports a debugger framework so that tooling can be developed to easily monitor Camel routes, trace messages and set breakpoints at points in a route etc.
The Debugger is an InterceptStrategy which can be applied to a DefaultCamelContext or SpringCamelContext to ensure that there is a DebugInterceptor created for every node in the DSL.
You can grab the debugger from the CamelContext via the Debugger.getInstance() method or via the Main.getDebugger() method - which returns null if it is not enabled.
To enable debugging from the main run
| Code Block |
|---|
java org.apache.camel.spring.Main -x
|
or
...
There is also a BacklogDebugger which allows to debug from JMX, and 3rd party tooling.
About the Debugger
The Debugger allows tooling or the likes to attach breakpoints which is being invoked when Exchanges are being routed.
Default Implementation
Camel provides a default implementation org.apache.camel.impl.DefaultDebugger which you can set on the CamelContext using the setDebugger method. Likewise you can get hold of the Debugger using the getDebugger method on CamelContext.
...
The
org.apache.camel.
...
and the debugger will be active.
Programmatically using the debugger
You can use the Spring org.apache.camel.spring.Main class directly to invoke your Camel routes using a spring XML file using debug as the following test case...
...
spi.Debugger has methods to attach and remove breakpoints. And to suspend/resume all breakpoints etc. You can also attach a condition to the breakpoint so it only reacts if the condition matches.
Debugging Camel Routes Using camel-test
If you are developing unit tests using the camel-test component, then the Debugger comes out of the box. From Camel 2.9: you would need to explicit enable the debugger, by overriding isUseDebugger() method and return true.
Example
In this unit test
...
We want to debug the following route:debugBefore method as shown:
...
...
...
...
...
Then from your Java editor just add a breakpoint inside the debugBefore method. Then fire up the unit test and wait for the Java editor to hit the breakpoint. Then you can inspect the Exchange during debugging while it advances during routing. The ProcessorDefinition and the id and shortName parameters is all information which tells you where in the route the breakpoint was hit.
...
There is also a debugAfter method which is invoked after the processor has been invoked. This allows you to see what happens to the Exchange right after it has invoked a processor in the route.
The screenshot below shows the Debugger in action. The IDE (IDEA) has hit the breakpoint and we can inspect the parameters. Notice how we can see that the message is to be send to the mock:a endpoint:
See Also
About the Debugger
The Debugger has access to every single DebugInterceptor for each node in the Camel EIP route. You can look up the individual interceptor by the Node ID where you can access
- the Breakpoint object
- the list of Exchanges sent to this node
- the Predicate used to determine if messages are logged to the list
Accessing the Route Definitions
You can easily access all of the available route definitions from the Main instance via the getRouteDefinitions() method.
| Code Block |
|---|
List<RouteType> routes = main.getRouteDefinitions();
|
...