camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kristofsajdak <>
Subject Re: Abstracting Routes using Components
Date Tue, 26 Oct 2010 21:12:02 GMT

jstrachan wrote:
> Or to say that a slightly different way; if you just want a 
> parameterised RouteBuilder, well thats just a bean; no need for 
> anything new, Camel can do that nicely today

I considered using a parameterized RouteBuilder, however it failed to
address some specific 

When using a solution based on parameterized RouteBuilders it requires you
to reference all 
RouteBuilder used in the CamelContext.

This becomes complex when nesting route abstractions within route
abstractions several levels 
deep. When using a top level RouteBuilder like
generateAndSignPdfRouteBuilder you are required 
to also declare the signPdfRouteBuilder reference which exposes the
direct:signPdf endpoint.


 <camelContext ...
    <routeBuilder ref="generateAndSignPdfRouteBuilder"/> 
    <routeBuilder ref="signPdfRouteBuilder"/>

public class GenerateAndSignPdfRouteBuilder extends RouteBuilder {

    public void configure() throws Exception {


public class SignPdfRouteBuilder extends RouteBuilder {

    public void configure() throws Exception {


In other words, you would have to know how GenerateAndSignPdfRouteBuilder is
in order to use it. 

The Route Component solution (II) doesn't require the RouteBuilders used to
be referenced
in the camelContext. It instantiates an endpoint which adds the Route
information to the 
camelcontext at runtime whenever a producer or consumer is started.

Would this concept be available in the ProtocolBuilder construct as well ? 
I do see the added value of using a ProtocolBuilder and declaring it as a
bean in spring 
but wouldn't you need to use some kind of generic component in the middle to
and add those builders on demand ? 


            <from uri="route:standardActions://out"/> 
            <to uri="route:generateAndSignPdf://in"/> 
            <to uri="mock:result"/> 
Another reason why I didn't consider the Parameterized RouteBuilder is the
risk of name clashes
. When nesting components several levels deep and/or reusing the same
RouteBuilder beans multiple times
 yet with different properties, this could lead to impredictable behaviour
when direct endpoints and routeIds are not unique within the CamelContext.

jstrachan wrote:
> ii) a parameterized RouteBuilder which is dependency injected using a 
> URI (which is kinda like Kristof's example code

Yeah, maybe the implementation of the RouteEndpoint class is somewhat
clumsy, but what I am trying to
do here is to pass header values to the nested route.

Normally you would go about this using the setHeader statement, however this
is quite verbose when
using xml dsl. 

	   <setHeader headerName="signatureReason"> 
            <setHeader headerName="signatureVisible"> 
            <setHeader headerName="xslUri"> 

That's why I figured i'd use the uri parameters to have some kind of
shorthand notation for assigning 
header values.


Maybe the implementation would be cleaner if properties are used only for
dependency injection.
The shorthand notation could define an interceptor on the from of the target 
RouteBuilder. The interceptor could then populate the headers 
when the exchange comes in.

Best regards,


View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message