camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: [DISCUSS] Schedule for starting development on Camel 3.0.0
Date Tue, 13 Mar 2012 07:39:45 GMT
On Sun, Mar 11, 2012 at 9:24 PM, Christian Müller
<> wrote:
> I assume somebody will take the stab to build Camel 2.10.0 in the next 4 -
> 6 weeks (if not, I will do it to be right here ;-) ).
> At present we have 276 issues assigned to this version [1]. 209 are already
> fixed.

Yeah but I wonder if we will be ready then? Camel 2.10 seems to have a
lot of new components, which is still in development.
Or lacks proper documentation etc. So I suggest the ppl who work on
these components to focus on getting it done.
Alternative we will have to remove some components from the release
kits - we do not want to release incomplete components (incomplete =
also if no docs)

> I think this is a good time to discuss whether the next version will be
> 2.11.0 or 3.0.0.
> *IF* the next version will be 3.0.0, we should have in mind that this
> version:
> 1) Probably needs more time than our normal 3 month schedule for a new
> minor version
> 2) Will break backwards compatibility and we want to provide a migration
> path for our users where possible.
> Because of this I would like to know:
> - Do we have to deprecate some more API's which we plan to drop in Camel
> 3.0.0?

Its often easier to @deprecate when we actually get started working on
Camel 3.0.
And do an actual change, which warrant a @ deprecation in 2.x.

> - Do we have to add some new API's stubs so that our users can start to
> migrate to the new API in Camel 2.10.0 (if possible)?

See above.

> Because of this I would like to see the following issues includes in Camel
> 2.10.0:
> - CAMEL-4955 <>  More and
> more user want to run Camel with Java 7. If we postpone it to Camel 3.0.0,
> we are very late with supporting Java 7. Apache Karaf supports Java 7 since
> version 2.2.3 - available since more than 6 month...

I suggest to setup a CI build at ASF that uses Java7.
Then we get test coverage using Java7 on linux and windows. And then
we can start fix any issues that exists due this.

I do not see a problem with supporting Java7 for Camel 2.10 onwards.
Only the OSGi world would need throughly testing, due
well its OSGi and surprises is always there. So we should have a CI
profile that runs the OSGi tests on the Java7 platform
with the Karaf version that supports Java7.

> - <>CAMEL-4778<>Also
> more and more user would like to start using Spring 3.1., some did it
> already. I think we should start to support Spring 3.1. officially in Camel
> 2.10.0.

Yeah would be nice to have support for both Spring 3.0 and 3.1 in Camel 2.10.

> And if the next version will not be Camel 3.0.0, I'm wondering for what we
> are waiting... ;o)

I think it takes longer time to do Camel 3.0, so I would suggest to
make room for Camel 2.11.
I suggest to taget Camel 3.0 for the end of 2012, eg Q4.

There is a fair number of internal optimizations and changes to the
routing engine that would be really good.
And to do that takes some time.

Also how the route model -> runtime is processed should be improved.
Currently there is a process where
interceptors, error handlers, on completions, etc. get woven directly
into the runtime routes. And the details is lost
from the route models that Camel exposes when running. So essentially
you cannot get a 100% 1:1 view of your Camel apps.

Combined with the routing engine optimizations, we can make this truly
1:1. And avoid to weave in the interceptors, error handers
in the route, but handle this during runtime. Then the runtime routes
and the design models can be 1:1.

This also avoids too deep stack frames.

And also allows to add/remove interceptors, etc at runtime to any
existing running Camel app. Which is some the SMX team
have requested. And people in the community. For example with Karaf
you can hot deploy a bundle that adds intercepting
to your Camel apps, and when you uninstall the bundle the interceptor
is gone. etc. This can also aid in other tooling
so you can hook in a diagnostic tool which can do more deep dive
investigations etc.

Also the route DSL should be tighten up a bit. Today its a bit too
lose, so you can specify onException in many areas where it does not
make sense.
Camel is kinda forgiving, and kinda "fix this itself" by adjusting the
model before its runtime created. But we would like to avoid this and
do no changes
to the design model at all, so we can have a 100% view of the route models.

We got some ideas for the Camel 3.0 sketched here

Also years ago we talked about to make the Message API immutable and
use a copy facade pattern

We may wanna take a 2nd look. Although we have optimized the logic a
fair bit to avoid excessive defensive copies
of the message during routing.

> [1]
> [2]
> Looking for your opinions,
> Christian

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message