camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 12:45:14 GMT
Am 26.09.2011 14:02, schrieb Claus Ibsen:
> On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
> <>  wrote:
>> Yes there are probably some undocumented changes. The question is though if
>> they would hit anyone. That is why I would like to do a release candidate
>> for 2.9. So
>> people can try to run their projects with the refactorings and we can even
>> react before the first official 2.9 release.
> With the current state of trunk as Camel 2.9.0, then I actually share
> a view to release early to give the community a chance to give it a
> spin.
> Also because Camel 2.9.0 is *not* going to be like any other regular
> minor releases we usually do.
> So doing 1-2 RC releases could be a good thing for the community.
Sounds good.
>> About the SPI changes I propose
>> ( This would of course be
>> a breaking change for anyone who actually uses these interfaces. The
>> questions is though how many people
>> would be hit. If you look closely at the interfaces then Policy is the only
>> one that is really likely to be used. The Debugger is probably also used
>> especially for tests. These were the only two points where I had to do
>> changes outside of camel-core to get the tests working.
> The SPI package is used for integrating interceptors
> (InterceptStrategy) as well as Policy, which is more common used.
> The Debugger API is a recent addition which allows you to debug from
> unit tests (as a kind of poor mans debugger), as
> well it allows 3rd party to build tooling for Camel in this area which
> people in the community ask for.
> How to get insight and debug their Camel apps. See for example that survey.
> You could even create an interactive debugger in Karaf Plugin, or have
> some integration from the Camel web console etc.
> I agree that this is a fairly new addition, and not so much used, so
> if it was *only* this area that was affected. Then we may
> be able to go ahead.
> But interceptors is used much more by people, and I am not keen on
> breaking those APIs.
> I guess there is no way to have support for both in the SPI, so we
> have the old API, as well as any new API?

We can have both versions but it is quite tricky to do it well.

For example spi.Policy. To keep compatiblity I can not rename or change 
the existing interface. So I have to find a name and place for the new 

Possible solutions:
1. spi.NewPolicy
2. spi.policy.Policy

I donĀ“t like the first solution whatever it is called. It would only 
make sense if we found a better name for it which I doubt.

The second solution is better. If we find a good package name where a 
subset of the interfaces can go it can make sense. Still I am not sure 
about it.

So if it is only a problem for very few people then I would opt for 
simply doing an incompatible change. But this is a really difficult 

Then there is the DSL like:

There we could support methods for the old and new interface so that 
should be easy. I think we could use an Adaptor from the old interface 
to the new interface to minimize code changes.

So the biggest problem is the naming and placing. I am open for any 


Christian Schneider

Open Source Architect
Talend Application Integration Division

View raw message