Gregory,
Weld+Jersey (and Weld+Anything) is going to be more and more common since CDI will be more and more of a base requirement
in any Java EE APIs. Weld was buggy in the beginning but Red Hat made great strides in fixing many, many bugs,
and Weld 3.0 (and 2.4) is very, very solid now.
Any integration will have it’s beginning growing pains, but CDI (Weld) + Jersey is an excellent combination,
and both projects are very responsive in fixing bugs quickly.
> On Aug 11, 2016, at 5:48 AM, Grzegorz <gregory.d3_at_gmail.com> wrote:
>
> 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 <mailto: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
>
>