[
https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975494#action_12975494
]
Claus Ibsen commented on CAMEL-3285:
------------------------------------
I have some comments on reviewing the source code
=========================================
1) RouteboxConfiguration
I dont think its advised to tie the configuration to a runtime instance of
Camel. eg you have instances of producer template, camel context in there.
All the logic you do to set parameters from the Map to the setters in
RouteboxConfiguration is not really needed, as Camel can do this for you.
2)
You start a producer template in RouteboxConfiguration but you never stop it.
eg you dont handle its lifecycle properly.
If you create a template using the API from CamelContext you can let
CamelContext handle its lifecycle and thus dont need to worry about it
3)
Use final modifier for internal fields, for shared resources such as queues (if
possible). This is better for the JVM. Otherwise you will have to use volatile
to ensure thread safety.
4)
Looks like the start logic in RouteboxServiceSupport may add the same routes
multiple times, because the stop logic doesn't remove the routes.
5)
PendingExchanges is not a setter/getter property end users can set!. Its an
internal information for graceful shutdown, to let it know that there are XXX
number of exchanges in flight that this route is currently processing. So
remove the getter/setter for it.
6)
Wonder if it would be better to extend SedaConsumer, DirectConsumer instead of
*not* doing that. I will have to re-check this as there is a lot of logic in
SedaConsumer which you may have to duplicate to make it work well.
7)
Looks like the asynchronous routing engine isn't supported as its supposed to.
I will have to revisit this as well.
9)
Having interfaces for RouteConsumer and RouteProducer is maybe overkill as
there doesn't seem to be anything out of the ordinary that a regular Consumer /
Producer. We may think about this if we want to enforce such a restriction.
> 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.
