On Mon, Oct 18, 2010 at 1:11 PM, James Strachan <james.strac...@gmail.com> 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. 2) Offer a fluent builder you would use inside the test method, something similar on my blog. The builder allows you to fine grained detail when the debugger should trigger. Kinda like a bit what we have with the NotifierBuilder which offers you to build a predicates using AND / OR and whatnot. http://camel.apache.org/notifybuilder.html But imagine a nice fluent API for debugging. The hard part is to come up with good and catchy builder names. debug().from("jms:*").when().sendTo("file:*").singleStep(new BreakpointSupport()) { // the poor mans closure here }; We could also have some configuration to easily filter out processing steps which you dont like / care about. Such as .convertBodyTo, .marshal etc. But for starters we could maybe shot for the filter and having debug fluent builder. Then later we can add nice builder methods to define fine grained when to invoke it. Having the filter allows you to let it filter out the noise. > > > On 16 October 2010 14:26, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi >> >> At first read this blog post >> http://davsclaus.blogspot.com/2010/10/paris-and-easier-camel-route-debugging.html >> >> Then this example with full source code. Notice how we use the debug >> method with the breakpoint >> to have Camel invoke the beforeProcess at each step in the route. This >> allows you easily to debug the route. >> See the screenshot in the blog post. >> >> public class DebugTest extends CamelTestSupport { >> >> public void testDebugger() throws Exception { >> // 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()); >> } >> }); >> >> // set mock expectations >> getMockEndpoint("mock:a").expectedMessageCount(1); >> getMockEndpoint("mock:b").expectedMessageCount(1); >> >> // send a message >> template.sendBody("direct:start", "World"); >> >> // assert mocks >> assertMockEndpointsSatisfied(); >> } >> >> �...@override >> protected RouteBuilder createRouteBuilder() throws Exception { >> return new RouteBuilder() { >> �...@override >> public void configure() throws Exception { >> // this is the route we want to debug >> from("direct:start") >> .to("mock:a") >> .transform(body().prepend("Hello ")) >> .to("mock:b"); >> } >> }; >> } >> } >> >> >> >> To do this requires the anonymous inner class (poor mans closures) and >> can be a bit verbose. >> What if we provide the debugger out of the box in the sense we have it >> implemented directly in the CamelTestSupport class. >> >> Then all you need to do is to override the beforeProcess class on the >> CamelTestSupport which makes the code less verbose >> This makes the code a bit smaller. And therefore all the end user need >> to do is to override either/or both beforeProcess, afterProcess to >> easily debug the route. >> >> We can also provide both approaches so you can do both if you like? >> >> Any thoughts? >> >> >> public class DebugTest extends CamelTestSupport { >> >> �...@override >> protected 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()); >> } >> >> public void testDebugger() 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(); >> } >> >> �...@override >> protected RouteBuilder createRouteBuilder() throws Exception { >> return new RouteBuilder() { >> �...@override >> public void configure() throws Exception { >> // this is the route we want to debug >> from("direct:start") >> .to("mock:a") >> .transform(body().prepend("Hello ")) >> .to("mock:b"); >> } >> }; >> } >> } >> >> >> >> -- >> Claus Ibsen >> Apache Camel Committer >> >> Author of Camel in Action: http://www.manning.com/ibsen/ >> Open Source Integration: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> > > > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
