You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/09/10 12:56:09 UTC
[DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
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).
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
Posted by Claus Ibsen <cl...@gmail.com>.
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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
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
Re: [DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
Posted by Christian Müller <ch...@gmail.com>.
+1
I'm ok with an API change for 2.11.0 (not for 2.10 or 2.9), if needed.
Best,
Christian
On Mon, Sep 10, 2012 at 3:47 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> What about a:
>
> public interface SourceAwareExceptionHandler extends ExceptionHandler {
> …add three methods….
> }
>
> Thus, no "old" code needs to change at all unless they want to use the new
> methods. They would need an instanceof if they do want to use the new
> methods.
>
> HOWEVER, we could also do an instanceof during the addExceptionHandler and
> wrapper any non-SourceAwareExceptionHandler handler with an instance that
> would forward all the methods to the old methods (dropping the source).
> Thus, all calls to getExceptionHandler would be given a SourceAware version.
>
> Dan
>
>
>
> On Sep 10, 2012, at 6:56 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
> > 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).
> >
> >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > FuseSource
> > Email: cibsen@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Re: [DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yes something a long the way proposed by Dan is likely to be a
suitable solution.
Been busy with other stuff lately. Also this is not a must heave
feature. But would be nice to have the source so people would know
where the problem came from.
On Mon, Sep 10, 2012 at 3:47 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> What about a:
>
> public interface SourceAwareExceptionHandler extends ExceptionHandler {
> …add three methods….
> }
>
> Thus, no "old" code needs to change at all unless they want to use the new methods. They would need an instanceof if they do want to use the new methods.
>
> HOWEVER, we could also do an instanceof during the addExceptionHandler and wrapper any non-SourceAwareExceptionHandler handler with an instance that would forward all the methods to the old methods (dropping the source). Thus, all calls to getExceptionHandler would be given a SourceAware version.
>
> Dan
>
>
>
> On Sep 10, 2012, at 6:56 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> 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).
>>
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: [DISCUSS] - API change on org.apache.camel.spi.ExceptionHandler
Posted by Daniel Kulp <dk...@apache.org>.
What about a:
public interface SourceAwareExceptionHandler extends ExceptionHandler {
…add three methods….
}
Thus, no "old" code needs to change at all unless they want to use the new methods. They would need an instanceof if they do want to use the new methods.
HOWEVER, we could also do an instanceof during the addExceptionHandler and wrapper any non-SourceAwareExceptionHandler handler with an instance that would forward all the methods to the old methods (dropping the source). Thus, all calls to getExceptionHandler would be given a SourceAware version.
Dan
On Sep 10, 2012, at 6:56 AM, Claus Ibsen <cl...@gmail.com> wrote:
> 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).
>
>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com