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.... Cheers, Ashwin... ----- --------------------------------------------------------- Ashwin Karpe Apache Camel Committer & Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com http://fusesource.com Blog: http://opensourceknowledge.blogspot.com http://opensourceknowledge.blogspot.com --------------------------------------------------------- -- View this message in context: http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3240590.html Sent from the Camel - Users mailing list archive at Nabble.com.
