On Mon, Sep 26, 2011 at 2:45 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> 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.
>
Yeah I cannot at first hand see any obvious good solution. Introducing
a NewXXX seems like a big temporary solution, as the NewXXX eventually
will replace the old API. So when this happens people have to migrate
yet another time.
> 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.
>
The spi is a good package name. If there is a better package name for
the future, then that could be a solution.
As the existing spi, and the new package can co-exists.
> 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.
>
Interceptors is used a fair bit. So its not just a few people.
> 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.
>
Okay what if the SPI / model stays as is for Camel 2.9.
But having clearly notice in the release notes, javadoc etc. that
there is changes planned.
Then for Camel 2.10 we can possible look into some sort of adaptor solution.
Maybe as a camel-adapter JAR you need to include on the classpath.
Which has the old API, and delegates to invoke the new API.
But again I don't know a good solution. Just throwing up a ball in the air.
> 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
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
