On 28 October 2010 05:15, Claus Ibsen <[email protected]> wrote: > On Wed, Oct 27, 2010 at 11:08 PM, kristofsajdak > <[email protected]> wrote: >> >> Great feedback guys, much appreciated ! >> >> >> jstrachan wrote: >>> >>> Agreed. If you kinda squint a bit and think of the route builders as >>> 'objects' and you want to compose 2 different routes together with >>> shared dependencies its a bit like 'constructors' and 'data hiding'. >>> >>> We have protocol A and B and we need to route the output of A to the >>> input of B; so rather than B needing to know the implementation detail >>> of A; we add a constructor parameter for B's input... >>> >>> class A extends ProtocolBuilder {...} >>> >>> class B extends ProtocolBuilder { >>> public B(String inputUri) { ... } >>> } >>> >>> // lets use Java code to simulate DI... >>> ProtocolBuilder a = new A(); >>> ProtocolBuilder b = new B(b.getOutputUri()); >>> >>> >>> we've now wired A and B together without B knowing anything about the >>> implementation detail of A. >>> >>> Its quite common for lots of protocols to be 'unix pipe-ish' with an >>> input and output; so we could have helper classes where there's >>> standard input/output endpoints like this to create a pipeline... >>> >>> CompositeProtocol composite = Protocols.pipeline(A.class, B.class, >>> C.class); >>> >>> where A:out -> B:in and B:out -> C:in. Indeed that could return a new >>> protocol; where composite:in maps to A:in and composite:out maps to >>> C:out >>> >>> But then this is sounding like just treating A, B and C as endpoints :) >>> >> >> Indeed that is adding more flexibility and will be quite usefull when >> nesting protocolBuilders several levels deep. >> >> However, I do have another point which relates to the specific use case of >> the customer I mentioned. >> >> Developers -> provide ProtocolBuilder implementations >> Solution consultants -> use ProtocolBuilders abstractions to wire the route. >> > > Yeah this sounds like a great use case and in demand in more and more > companies. > This is something that we hear more often and often. > > > >> Practically, it seems to me that the easiest way of achieving that is to >> create one or more modules >> which contain the ProtocolBuilders implementation classes and the spring xml >> files which configure them. >> >> Whenever a solution consultant starts working on a new customer >> implementation he could use an archetype to create a module which has the >> dependencies to the ProtocolBuilder modules preconfigured. >> >> The solution consultant would then create the route in xml dsl and use >> camel:run to execute the route, this plugin goal would in turn bootstrap all >> the ProtocolBuilder configurations located in >> classpath*:META-INF/spring/.xml, making them available to the route at >> runtime. >> >> Now my question is: When you define a ProtocolBuilder in the spring xml, >> would it get initialized and added to the CamelContext at that point ? I >> mean I don't think it's a good idea to initialize and add all the >> ProtocolBuilders which are available in classpath*:META-INF/spring, but >> neither do I want to leave it up to the solution consultant to explicitly >> define which builders get initialized. >> >> E.g. Like with the Parameterized RouteBuilder concept I mentioned earlier >> >> <camelContext ... >> <routeBuilder ref="generateAndSignPdfRouteBuilder"/> >> <routeBuilder ref="signPdfRouteBuilder"/> >> .... >> >> Which is just way to complex for non developers in my opinion. >> > > You can use annotations, for example the Spring @Component annotation. > You would then @Component annotate the RouteBuilder to be included. > > Then you can use the <contextScan/> tag > See http://camel.apache.org/spring.html > > This means its standard Spring stuff to annotate and use the spring > XML tag to enable its context scanner. > > All you do in Camel is to add this <contextScan/> inside the <camelContext> > tag.
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. -- James ------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
