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
needs.
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.
E.g.
<camelContext ...
<routeBuilder ref="generateAndSignPdfRouteBuilder"/>
<routeBuilder ref="signPdfRouteBuilder"/>
....
public class GenerateAndSignPdfRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:generateAndSignPdf")
...
to("direct:signPdf");
}
}
public class SignPdfRouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:signPdf")
...
}
}
In other words, you would have to know how GenerateAndSignPdfRouteBuilder is
implemented
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
instantiate
and add those builders on demand ?
E.g.
<route>
<from uri="route:standardActions://out"/>
<to uri="route:generateAndSignPdf://in"/>
<to uri="mock:result"/>
</route>
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">
<constant>JustForFun</constant>
</setHeader>
<setHeader headerName="signatureVisible">
<constant>true</constant>
</setHeader>
<setHeader headerName="xslUri">
<constant>com/xti/poc/camel/route/sample1/krusty.xsl</constant>
</setHeader>
That's why I figured i'd use the uri parameters to have some kind of
shorthand notation for assigning
header values.
?signatureReason=JustForFun&signatureVisible=true&xslUri=com/xti/poc/camel/route/sample1/krusty.xsl
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,
Kristof
--
View this message in context:
http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3237827.html
Sent from the Camel - Users mailing list archive at Nabble.com.
