[
https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977369#action_12977369
]
Ashwin Karpe edited comment on CAMEL-3285 at 1/4/11 12:39 PM:
--------------------------------------------------------------
Hi Kristof,
We agree on a) and b) and the current implementation clearly follows this.
In the current implementation of the routebox component, there is only one
inner context created for a unique endpoint name. The endpoint name is then
tied uniquely to its innerContext and host multiple inner routes. This should
meet your requirement relating to encapsulation, hosting and strategy/map based
payload indirection to inner routes.
As for point c) in your comment, the URI definition is where the divergence
with your requirement is indeed present and I am aware of this.
My design/implementation choices were guided by the following reasoning given
below
--------------------------
Currently in Camel, Protocols/URI schemes enable binding & registration of a
specific component known to the Camel Context which is then used as a factory
to create specialized endpoints of a given type (e.g http, jms etc). The
protocol/URI scheme mapping to a component registration is done at context
creation automatically using an API called addComponent(String componentName,
final Component component) .The only exception is when a routebuilder is used
to add a component.
Therefore, you will find that when you add a camel component maven dependency
in your pom file the component is automatically registered under its fixed
name. This happens via a file which is scanned during context creation and is
present for every component in
.../trunk/components/camel-routebox/src/main/resources/META-INF/services/org/apache/camel/component/routebox
which contains a single entry for its associated component. The name of the
file (routebox) is wired to the URI scheme and the component associated is
added to the component list. Following this, camel now has the ability to
create the requisite endpoints.
Now coming to the answer you are looking for... The reason James talked about a
ProtocolBuilder akin to a RouteBuilder was so that this magic of mapping
"bookstore" to the Routebox component could be performed by the API which the
user could write code for (or maybe not, based on the design)... This
addComponent() would need to be done every protocol (bookstore, bookstore1,
mybookstore etc) you were planning to use.
Also, since the URI scheme suddenly became cheap, you could add all manner of
names for components and potentially override the values of well known
protocols. You could run into name clashes in different ProtocolBuilders trying
to do the same thing.
RouteBuilders currently can do the same for you. You can add a line to your
configure method to do an addComponent("bookstore", RouteComponent")
-----------------------------
I decided not to pursue this road since RouteBuilders currently can do the same
for you and the ProtocolBuilder was in my view over-engineering for little
gain. You can add a line to your configure method to do an
addComponent("bookstore", RouteComponent") even now and then do a
bookstore:bookstore_routes?...
instead of
routebox:bookstore_routes?...
with an exchange header ROUTE_DISPATCH_KEY=addToCatalog so the payload can be
indirected to URI seda:addToCatalog.
BTW, I spoke to James and Claus a few weeks ago in early December about my
design and implementation strategy. I also rotated this many times in my own
mind, ran these ideas by an existing customer with similar needs regarding
pros/cons and arrived at this point. James did think that my design was proper
(though not how he had envisioned it in the beginning) and asked me to go ahead
and contribute the code as seen in my current implementation. I also spoke to
Claus briefly and he was quite happy with the implementation plan.
I am not saying this is the final form for this component. I am happy to take
on any thoughts, ideas and/or patches you may have and re-factor the component
appropriately.
Sorry about the rather long winded answer. I hope this given you a sense of
where I am coming from.
Cheers,
Ashwin...
was (Author: akarpe):
Hi Kristof,
We agree on a) and b) and the current implementation clearly follows this.
In the current implementation of the routebox component, there is only one
inner context created for a unique endpoint name. The endpoint name is then
tied uniquely to its innerContext and host multiple inner routes. This should
meet your requirement relating to encapsulation, hosting and strategy/map based
payload indirection to inner routes.
As for point c) in your comment, the URI definition is where the divergence
with your requirement is indeed present and I am aware of this.
My design/implementation choices were guided by the following reasoning given
below
--------------------------
Currently in Camel, Protocols/URI schemes enable binding & registration of a
specific component known to the Camel Context which is then used as a factory
to create specialized endpoints of a given type (e.g http, jms etc). The
protocol/URI scheme mapping to a component registration is done at context
creation automatically using an API called addComponent(String componentName,
final Component component) .The only exception is when a routebuilder is used
to add a component.
Therefore, you will find that when you add a camel component maven dependency
in your pom file the component is automatically registered under its fixed
name. This happens via a file which is scanned during context creation and is
present for every component
trunk/components/camel-routebox/src/main/resources/META-INF/services/org/apache/camel/component/routebox
which contains a single entry for its associated component. The name of the
file (routebox) is wired to the URI scheme and the component associated is
added to the component list. Following this, camel now has the ability to
create the requisite endpoints.
Now coming to the answer you are looking for... The reason James talked about a
ProtocolBuilder akin to a RouteBuilder was so that this magic of mapping
"bookstore" to the Routebox component could be performed by the API which the
user could write code for (or maybe not, based on the design)... This
addComponent() would need to be done every protocol (bookstore, bookstore1,
mybookstore etc) you were planning to use.
Also, since the URI scheme suddenly became cheap, you could add all manner of
names for components and potentially override the values of well known
protocols. You could run into name clashes in different ProtocolBuilders trying
to do the same thing.
RouteBuilders currently can do the same for you. You can add a line to your
configure method to do an addComponent("bookstore", RouteComponent")
-----------------------------
I decided not to pursue this road since RouteBuilders currently can do the same
for you and the ProtocolBuilder was in my view over-engineering for little
gain. You can add a line to your configure method to do an
addComponent("bookstore", RouteComponent") even now and then do a
bookstore:bookstore_routes?...
instead of
routebox:bookstore_routes?...
with an exchange header ROUTE_DISPATCH_KEY=addToCatalog so the payload can be
indirected to URI seda:addToCatalog.
BTW, I spoke to James and Claus a few weeks ago in early December about my
design and implementation strategy. I also rotated this many times in my own
mind, ran these ideas by an existing customer with similar needs regarding
pros/cons and arrived at this point. James did think that my design was proper
(though not how he had envisioned it in the beginning) and asked me to go ahead
and contribute the code as seen in my current implementation. I also spoke to
Claus briefly and he was quite happy with the implementation plan.
I am not saying this is the final form for this component. I am happy to take
on any thoughts, ideas and/or patches you may have and re-factor the component
appropriately.
Sorry about the rather long winded answer. I hope this given you a sense of
where I am coming from.
Cheers,
Ashwin...
> Create a new blackbox component which can encapsulate routes using a
> specialized ProtocolBuilder endpoint (similar to RouteBuilder)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-3285
> URL: https://issues.apache.org/jira/browse/CAMEL-3285
> Project: Camel
> Issue Type: New Feature
> Reporter: Ashwin Karpe
> Assignee: Ashwin Karpe
> Fix For: 2.6.0
>
> Attachments: camel-routebox-20101220.zip, routebox.diff
>
>
> Given below is the discussion forum thread that spawned this thought.
> http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-td3234703.html#a3234703
> Component requirements:
> Need a Camel component (called Backbox, maybe) that can nicely expose a
> ProtocolBuilder endpoint that does the following
> a> Instantiate route definitions/route(s) configured in Spring or DSL at
> startup
> b> Launch a Producer or Consumer with a well known protocol(s) so that a
> client can invoke it (could be direct or seda initially but could be any
> protocol... really) . Must support multiple consumer endpoints and routes
> using a URI scheme.
> c> redirect received payloads (with marshalling into an exchange if
> necessary) to the inner route(s) since they are launched and started. If
> there are multiple inner routes with many consumers, we could expect the user
> to provide a clue using the payload and/or an exchange property as to how the
> payload should be routed.
> d> Extend from a Default Consumer, Producer, Endpoint and Component.
> e> Internally manage inner route lifecycles and operations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
