camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [DISCUSS] - Easier Camel route debugging from Camel Test Kit
Date Mon, 18 Oct 2010 14:10:38 GMT
On 18 October 2010 14:56, Claus Ibsen <> wrote:
> On Mon, Oct 18, 2010 at 1:11 PM, James Strachan
> <> wrote:
>> Good idea!
>> We should make it as easy as possible to set conditional breakpoints
>> in your debugger using the available context and your IDE. e.g.
>> * the id of the Definition node in the route (stop at a specific point
>> in a route). e.g. condition: getDefinition().getId() == "AMC"
>> * the kind of node (e.g. on a ToDefinition in all routes. e.g.
>> condition: getDefinition().getShortName() == "to"
>> * the value of a header on a message
>> A common issue with Camel is there are often many threads and inputs
>> all processing concurrently and breakpoints can fire at any point in
>> any route which can be confusing. I wonder if we could add some kind
>> of 'flow' conditional method, so we could let the IDE stop at a common
>> breakpoint but it would only fire subsequently for one complete flow
>> through the route until we told the runtime to 'continue'. Kinda like
>> a virtual 'step' operation.
>> e.g. imagine we had a isFlowMessage() function we could use as a
>> conditional breakpoint we set in the IDE. This method returns true for
>> the first invocation; a header is added to the message; it then
>> returns false for all other invocations until its the next step in the
>> flow for the original message. Then it'd be much easier to 'step
>> through' camel routes.
> We could probably do 2 things
> 1)
> Let CamelTestSupport offer the beforeProcess / afterProcess methods
> which end users can override to easily just debug the test they are
> doing.

I'm not sure if I explained myself terribly well in my previous ramble
- I was basically imagining us adding a few more methods available to
the beforeProcess() debug context, so when you add a breakpoint in
your IDE then, say, in IDEA, right click on the breakpoint ->
Properties -> Condition - you can then easily enter a mini-DSL in the
"Condition" text field where you can describe the way you want to
debug the route. So providing a few new methods to access the current
Definition node, its id, shortName, the current message and so forth
so its easy to filter out noise.

So rather than hacking your Java code to add a DSL, I was imagining
using this kind of thing most often inside the Breakpoint UI in your
IDE. Though its cool hacking a DSL in your test case/code too - I'm
just wondering how much we can just use the existing IDE features
(with a few new helper methods here or there).


Open Source Integration

View raw message