It really turned out to be a regression bug, introduced in January 2015.
And is related to the Weld extension and bean validation modules.
Because without dependency to Weld, my custom exception mapper has a higher
priority than the one provided by jersey-bean-validation module.
I've filled a bug report with ID JERSEY-3153.
I'm never ever going to use Weld + Jersey again... I'm so tired with this
combination. Through the last two years I've encountered around 10 bugs
already. I'm really tired.
Anyway, thanks Pavel for the tip.
Regards,
Greg
2016-08-10 12:02 GMT+02:00 Pavel Bucek <pavel.bucek_at_oracle.com>:
> Hi Greg,
>
> seems like a regression. (Its not definitely something we did
> intentionally, but I know there were some fixes related to bean validation,
> which might have changed the behavior. Generally, user defined @Provider
> should have always higher priority than anything provided by Jersey).
>
> Can you please file a bug, ideally with a reproducer?
>
> Thanks,
> Pavel
>
> On 10/08/16 11:39, Grzegorz wrote:
>
> Hi all,
>
> In one of my projects I've already upgraded Jersey from version *2.14* to
> *2.23*. But I'm struggling many hours with one problem.
> My project defines its own ExceptionMapper for a "ValidationException",
> but unfortunately Jersey already has a built-in exception mapper for this
> exception: org.glassfish.jersey.server.validation.internal.
> ValidationExceptionMapper and I cannot override it.
>
> I've also tried to use @Priority annotation for my custom mapper, but
> unfortunately Jersey doesn't take it into account. In the previous Jersey
> version (2.14) my mapper used to overwrite the built-in one. And IMHO it
> was very intiuitive.
>
> What is going on? Is it a regression bug or an intended change?
>
> Kind Regards,
> Greg
>
>
>