Page History

...

This is a mindmap of ideas for improving Camel 3.0. Fell free to discuss this on the Camel Mailing Lists if you have other ideas or feedback.

JDK support

(+1: claus)

We should drop support for JDK6, and require JDK7 as minimim version. eg build and compile the release with JDK7.
We should aim to be compatible with JDK8.

...

Split camel-core into multiple parts (hadrian)

(+1: cmueller, hadrian, claus)

Claus: Important to be 99+% backwards compatible with Camel 2.x.

There are multiple benefits and less constraints. A separate api jar would allow the definition of a 'route container' which is currently one of the roles of the CamelContext. This allows primarily alternative implementations of camel for constrained environments (such as real time systems, for instance). Processors/Routes/Components written against the api could be deployed on any camel implementation (as long as all necessary features are supported).

...

• * -> api
• end user config code -> builder
• builder -> impl

...

Avoid shading google concurrent linked map in camel-core

...

The shaded Google concurrent map should IMHO be pluggable, so people can run without this as default. And then people can install that google JAR on their classpath and Camel can pickup and use that. This JAR only helps in SMX/Karaf installations when having concurrent startup of many Camel apps. For regular users this does not bring any benefits to the table. This can help slim down the size of the camel-core JAR.

We can either auto detect the google class, as people did in the past with JDK1.3/1.4 and the apache commons collection. eg using commons collection on JDK1.3 and not in JDK1.4 as it had that out of the box.

Define scope and rules for camel-core packages (champion?)

In extension to the previous paragraph each camel package should have a clear scope that defines what to put in the package and what not. There should be rules that define what dependencies are allowed for classes in a package. The minimum goal is to guarantee that by following the rules dependency cycles can not happen. Additionally the rules should minimize dependencies between packages to achieve loose coupling between packages and high coherence inside a package.

More flexible routes at runtime (claus)

(+1: hadrian)

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.

Fix routes with multiple inputs (claus)

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 actual solution will depend on the api refactoring.

Route initialization logic for Java DSL and XML DSLs (claus)

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 (claus)

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 (claus)

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)

Message History EIP/Message Store (Christian Ohr)

(+1: hadrian, claus)
We should make this EIP easier to use for end users, but offering a better public API. And also have a pluggable message store, with filters that can filter what should be stored. As well pluggable marshallers so people can marshal data from Exchange into a format the message store can store (BLOB, XML, JSon etc.).
A Message Store could provide transparent persistence to various EIP patterns (or used directly). Implementations would handle the mapping to the underlying database or file system or NoSQL or memory or whatever.
Message Store implementations are already there in various places, using different approaches, like in Stream Caching (only file system), AggregationRepository or IdempotentRepository. A Message Store is requested for in other places like Reliable stream resequencing (CAMEL-949) or Persistent Dead Letter Queue (CAMEL-4575). And there might be other areas (seda, bam) that might benefit as well.

Dependency Upgrades

We should upgrade Jetty to 8.x as minimum. And if possible support Jetty 9.x which is in the works.
Currently we are stuck on 7.x due CXF / Karaf etc uses that old version, and thus we have been good citizen to align and use same version.
AMQ is also using older Jetty, but that is easier to upgrade

In extension to the previous paragraph each camel package should have a clear scope that defines what to put in the package and what not. There should be rules that define what dependencies are allowed for classes in a package. The minimum goal is to guarantee that by following the rules dependency cycles can not happen. Additionally the rules should minimize dependencies between packages to achieve loose coupling between packages and high coherence inside a package.

More flexible routes at runtime (claus)

(+1: hadrian)

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.

Fix routes with multiple inputs (claus)

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 actual solution will depend on the api refactoring.

Route initialization logic for Java DSL and XML DSLs (claus)

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 (claus)

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 (claus)

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)

Message History EIP/Message Store (Christian Ohr)

(+1: hadrian)
We should make this EIP easier to use for end users, but offering a better public API. And also have a pluggable message store, with filters that can filter what should be stored. As well pluggable marshallers so people can marshal data from Exchange into a format the message store can store (BLOB, XML, JSon etc.).
A Message Store could provide transparent persistence to various EIP patterns (or used directly). Implementations would handle the mapping to the underlying database or file system or NoSQL or memory or whatever.
Message Store implementations are already there in various places, using different approaches, like in Stream Caching (only file system), AggregationRepository or IdempotentRepository. A Message Store is requested for in other places like Reliable stream resequencing (CAMEL-949) or Persistent Dead Letter Queue (CAMEL-4575). And there might be other areas (seda, bam) that might benefit as well.

Remove not used components

...

• create a single type converter registry available as OSGi service to all bundles serving as a single registry to lookup converters or to add/remove converters from custom bundles.

Easier commit/rollback for component developers

...