camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Abstracting Routes using Components
Date Thu, 28 Oct 2010 14:05:47 GMT
On 28 October 2010 15:01, Ashwin Karpe <> wrote:
> Hi JStrachan,
>> Agreed. Protocols are just kinds of Component. My initial
>> ProtocolBuilder was a bit of a strawman focussing more on them also
>> being a RouteBuilder to get the Java DSL; but in many ways its
>> probably more important to think of them as being Components first and
>> foremost - the Spring DSL / RouteBuilder stuff is more an
>> implementation detail in how we wire those things.
> I couldn't agree more with what you just said. There are several potential
> ways to inject routes into the ProtocolComponent (Registry, RouteDefinition,
> RouteContext) etc. A component could solicit these as easily.
> It is more important that the Component and Endpoint to be a proper Camel
> entities and follow from the core building blocks. ProtocolBuilder (aka more
> specialized/extended abstract RouteBuilder) is more like developer glue/stub
> code to make the route known to the camel context...
> If the layering/blackboxing was unimportant we would not need a component.
> We could use the existing <routeBuilderRef> to achieve the same end...
> As for creating a child context per blackboxed endpoint, I am afraid, while
> we could get good encapsulation/management of individual endpoints and their
> routes, it could cause a proliferation of contexts in the JVM and be way
> more overhead if the route uses many such endpoints. This could be
> inefficient and a lot of unnecessary overhead. I am leaning towards making
> this an optional thing triggered by a URI query parameter....

Unless we figure out a way to create a really lightweight child
CamelContext which doesn't do a whole lot other than provide a naming
scope for private endpoints?

Twitter: jstrachan

Open Source Integration

View raw message