It's funny but I was just wrestling with this issue. I decided in my
particular case not to use the .validate() but instead to use the
.fliter().method("MyBeanValidator") which does a Boolean whether to
continue or not. But in the validator I have endpoints injected for error
handling. In this case I'm firing off emails to administrators. But if
you can inject an endpoint then it can be used for pretty much anything.
That way I'm not slinging exceptions and setting retries. I find that
mechanism rather clunky and better for a general safety net for the truly
unexpected than for other errors.
Obviously Camel has a lot of different ways to do things so it's pretty
much a matter of taste I think.
On Mon, Aug 1, 2016 at 10:03 AM, Matt Sicker <boa...@gmail.com> wrote:
> I have a common pattern right now of adding .validate() to several REST DSL
> params since the .required() swagger DSL appears to be a suggestion and not
> a validation. Since my REST DSL is spread across several routes, I'd like
> to use some sort of shared error handling. Now I see there are two good
> methods here that I'm debating between:
>
> 1. Use onException() in an abstract class and have all my RouteBuilders
> inherit from that in order to reuse the same onException() block (which is
> somewhat annoying because if you use the XML DSL instead, the same
> <onException/> applies to the whole CamelContext apparently, but not when
> you use the Java DSL).
>
> 2. Export an ErrorHandlerFactory service bean and reuse that in each
> RouteBuilder on the specific routes that have a .validate().
>
> I'm using Camel 2.16.2 if that matters.
>
> --
> Matt Sicker <boa...@gmail.com>
>
