Am 26.09.2011 14:02, schrieb Claus Ibsen:
On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
<ch...@die-schneider.net> 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
(https://issues.apache.org/jira/browse/CAMEL-4475). 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
version.
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
question.
Then there is the DSL like:
from("").policy(myPolicy)
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
suggestions.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
