On Mon, Sep 10, 2012 at 1:08 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> How about adding a new ExceptionHandler interface and deprecating the old
> one. We can then allow both in Camel 2.x and remove the old one in Camel 3.
> This way we do niot introduce an incompatibility and give people some time
> to switch.
>
> Downside is that it requires some additional code in 2.x and the question is
> of course how to name the new interface.
>
Yeah that is maybe the best overall solution, but the downside is that
there would be code to have to check for if its the old or new
interface and call the appropriate method.
The new API should extend the old API, then any older components that
have not migrated, can call the old APIs.
And the downside is that we would then stick to the new API name for
Camel 3.0 onwards. So naming the new API is harder.
(new API I mean the name of the interface)
if (handler instanceof old) {
... old call here
} else if (handler instanceof newcode) {
... new call here
}
But that is doabled for the ASF Camel components, as we can adjust
code accordingly. But not the most fun stuff to do though.
> Christian
>
> Am 10.09.2012 12:56, schrieb Claus Ibsen:
>
>> Hi
>>
>> See ticket, and if you got the time the nabble link
>> https://issues.apache.org/jira/browse/CAMEL-5587
>>
>> The API on org.apache.camel.spi.ExceptionHandler has 3 methods for
>> handling exceptions,
>>
>> CAMEL-5587 is a ticket to enhance that API with a new parameter that
>> has the source that called the handler.
>> This allows end users to know the source, and get additional details,
>> such as if it was from a consumer, which consumer
>> and the endpoint etc.
>>
>> This is needed when you for example have a custom exception handler
>> and use it for many Camel endpoints (routes etc).
>>
>> Mind this only affects either
>> - component writers if using this API
>> - end users if using a custom exception handler.
>> Both of these cases is not often used.
>>
>>
>>
>> As this API is not backwards compatible we could
>> a) wait for Camel 3.0
>> b) introduce the change
>> c) introduce the change, but add the 3 old methods to
>> org.apache.camel.spi.ExceptionHandler and mark the as @deprecated
>>
>> Ad a)
>> We can wait a long time then.
>>
>> Ad b)
>> This requires older components to be recompiled to support newer Camel
>> releases (if the component uses the API directly).
>>
>> Ad c)
>> This allows older components to be compatible with newer Camel
>> releases (if the component uses the API directly).
>>
>>
>>
>>
>>
>
>
> --
> 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.com
Author of Camel in Action: http://www.manning.com/ibsen
