Page History

...

Clearer Architecture of Camel Core

Goals:

• The camel components should know as little as possible about camel core
• The classes needed to setup camel should be separate from the things needed at run time

...

The internal routing engine should be optimized. See more details at Camel 2.x Speed optimizations.

Tighten up route definitions

Currently cross cutting concerns such as error handlers, interceptors, onCompletion etc. can be define anywhere in the route. We should tighten this up and only allow this to be configured in the start of the route. This also ensures when end users use code assistance in their route development, the IDE will not popup a big list which includes these cross cutting concerns. See also next note. (ProcessorDefinition will therefore be trimmed)

More flexible routes at runtime

When routes is added in Camel 2.x architecture, global cross cutting concerns such as error handlers, interceptors, onCompletion etc. is applied when the route is added. We need to separate this and have those applied during routing. The Channel needs to do this and therefore it must be more dynamic than its currently is. And we need to enlist the various global cross cutting concerns by their xxxDefintions in the CamelContext, so we can access them at any time. This allows end users also much more easily to add/remove interceptors, error handlers and whatnot at runtime. And it makes it much easier to add routes generated from JAXB or other sources, as we don't need to prepare or anyhow mold the RouteDefinition given. See ticket CAMEL-3024 for some details.

Route initialization logic for Java DSL and XML DSLs

The Java DSL does its route initialization slightly a bit different than the XML DSLs, due the nature of it, and the fact the fluent builders can do additional logic, which the JAXB model of XML DSLs does not. We should align the initialization logic so Java DSL and XML DSLs does the same thing. They setup the pure model at first. So the configure method in the RouteBuilder should setup the model as the XML DSL would do. Then the prepare route logic which follows could be the same in all cases. This would also allow us to ensure when people use multiple RouteBuilder classes in Java DSL, then context scoped onException, interceptors is applied for all RouteBuilders.

Add OnException, Interceptor, etc. to JAXB model for a CamelContextDefinition

Configuring context scoped onException, interceptors etc. is woven into the RouteDefinition as part of the route initialization logic. When we have a dynamic routing engine (see above) that can at runtime support this without the need for woven into the routes. Then we should also ensure the context scoped onException, interceptors etc. is available in a CamelContextDefinition. This ensures the models is always 100% kept as it was provided, and we can fully export the model to XML and other languages (having a supported render).

Tighten up route definitions

Currently cross cutting concerns such as error handlers, interceptors, onCompletion etc. can be define anywhere in the route. We should tighten this up and only allow this to be configured in the start of the route. This also ensures when end users use code assistance in their route development, the IDE will not popup a big list which includes these cross cutting concerns. See also next note. (ProcessorDefinition will therefore be trimmed)

Support for asynchronous transactions

When using the asynchronous routing engine it would be desirable of transactional context could be propagated to the new threads.
This requires the TX manager supports suspend/resume on the TX. G.Nodet have worked a bit on this. See CAMEL-2902. Also see CAMEL-2729.

With the Asynchronous Routing Engine it would be great if we could support asynchronous transaction as well. See CAMEL-2729 and CAMEL-2902

Remove @deprecated

@deprecated features, methods, etc. is to be removed.

...

The current implementation of routes with multiple inputs is to clone the route, which means you essentially got 2+ routes if a route has multiple inputs. However routes with multiple inputs is seldom used. The correct implementation is to only create one route but have multiple input consumers. This change will require a bit of change in current code as it relies on the only 1 input consumer on the route.

Up-to-date Scala DSL

The Scala DSL is slightly out of date as we have improved the DSL a bit here and there. We should check the gap and ensure the Scala is up-to-date.

...

Currently its only the Routing Slip, Recipient List and Dynamic Router which are avail as @annotation as well. We could add more EIPs as annotations such as Splitter.
And also maybe annotations for AggregationStrategy to make this less Camel API dependent, so you can use a plain POJO for that.

Asynchronous transactions

With the Asynchronous Routing Engine it would be great if we could support asynchronous transaction as well. See CAMEL-2729 and CAMEL-2902

Unified statistics

Currently the performance statistics is only avail when using JMX. We should allow those stats to be enabled regardless if JMX is enabled or not. Then we can use those stats from the web console. This also allows to expose those stats in the cloud where JMX is often not possible to be used.

...