That sounds like an interesting approach. Are you using a ProducerTemplate
then in the validation bean?
On 1 August 2016 at 10:38, Brad Johnson <brad.john...@mediadriver.com>
wrote:
> 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>
> >
>
--
Matt Sicker <boa...@gmail.com>
