On 18 October 2010 14:56, Claus Ibsen <[email protected]> wrote: > On Mon, Oct 18, 2010 at 1:11 PM, James Strachan > <[email protected]> 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). -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
