Hi Claus,

I'm playing with CamelTestSupport in new components.

Overriding beforeProcess() method is very helpful to reduce the verbosity.

+1 to override it in the CamelTestSupport.

Regards
JB

On 10/16/2010 03:26 PM, Claus Ibsen 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");
             }
         };
     }
}



Reply via email to