On 28 October 2010 15:01, Ashwin Karpe <[email protected]> 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? -- James ------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
