camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james.strac...@gmail.com>
Subject Re: [DISCUSS] - Easier Camel route debugging from Camel Test Kit
Date Mon, 18 Oct 2010 11:11:32 GMT
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.



On 16 October 2010 14:26, Claus Ibsen <claus.ibsen@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/

Mime
View raw message