Claus Ibsen-2 wrote:
>
> 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.
>
>
> Maybe there are other ways to make this easier? Any suggestions?
>
It does sound like a very nice way to add RouteBuilders in a non verbose
way.
However, if you go about it in that way, how would you limit the number of
RouteBuilders
being initialized and addded to the CamelContext ?
That is, if we are still talking about using one dependency to a module
which contains all of the Route abstractions. I guess you could have one
module for one RouteBuilder and add / remove those as dependencies to your
module. But that would require the non technical person to start editing the
pom.xml.
Maybe that's not a big deal but I would like to avoid the extra hassle if I
can ;-)
jstrachan wrote:
>
> Agreed.
>
> We can also use the same kind of tricks with Component/Endpoint as
> with Protocol; i.e. if you don't use a Protocol then nothing much
> happens. Even when you do use a Protocol (like using a Component),
> things only really kick in when you start really using them & routing
> to/from them.
>
Sounds good to me.
jstrachan wrote:
>
>
> Yeah. I guess usually with Component/Endpoint type stuff, we tend to
> use URI parameters to configure 'middleware type stuff'; for
> Protocols, maybe the URIs should be 'protocol stuff' i.e. setting
> headers which can be used inside the protocol to respond differently.
>
> Or to say that a different way; if the endpoints into and out of a
> Protocol are all a simple standard kind (say the "local" endpoints
> mentioned previously), there's not going to be a whole lot of
> configuration parameters for those kinds of endpoints as they are
> kinda like "direct" endpoints, so we can reuse the URI parameters as
> short hand for passing in configuration/header information to the
> protocol?
>
>
yes.
I really think this adds a lot of value for non technical people (e.g.
solution consultants).
The developers would take care of configuring ProtocolBuilder 'templates'
and injecting them with global properties and middleware stuff. The solution
consultants would further enhance the Builders with
protocol stuff using the URI parameters.
This saves them the trouble defining beans for every variation of a
particurlar ProtocolBuilder template.
E.g.
<route>
<from uri="direct:start"/>
<to uri="route:foo?foo=bar"/>
<to uri="route:foo?foo=noBar"/>
<to uri="mock:result"/>
</route>
I guess you'd need to define the Builder with a prototype scope to pull
something like this off ?
Best regards,
Kristof
--
View this message in context:
http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3240855.html
Sent from the Camel - Users mailing list archive at Nabble.com.
