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
