How to override a built-in exception mapper in Jersey 2.23?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to override a built-in exception mapper in Jersey 2.23?

Grzegorz
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to override a built-in exception mapper in Jersey 2.23?

Pavel Bucek-2

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to override a built-in exception mapper in Jersey 2.23?

Grzegorz
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 <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to override a built-in exception mapper in Jersey 2.23?

Lenny Primak
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 <[hidden email]> 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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to override a built-in exception mapper in Jersey 2.23?

Lenny Primak-2
In reply to this post by Grzegorz
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 <[hidden email]> 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 <[hidden email]>:

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




signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MessageBodyReader/Writer selection

Richard Sand
In reply to this post by Lenny Primak
Hi all - 

I know this topic has come up before but I haven't been able to discern a conclusive answer. I have two MessageBodyReaders, one that handles a parent type (call it MyBaseClass) and another that handles a more specific subclass (call it MySubClass), and I'm struggling to find a way to have Jersey use the reader for the subclass, because the base class reader is also returning true for isReadable.

public class MyBaseClassMessageBodyReader<T> implements MessageBodyReader<JsonDeserializer<T>> {
   public boolean isReadable(Class<?> type, Type genericType, java.lang.annotation.Annotation[] annotations, MediaType mediaType) {
       return MyBaseClass.class.isAssignableFrom(type);
   }
...
}

public class MySubClassMessageBodyReader<T> implements MessageBodyReader<JsonDeserializer<T>> {
   public boolean isReadable(Class<?> type, Type genericType, java.lang.annotation.Annotation[] annotations, MediaType mediaType) {
       return MySubClass.class.isAssignableFrom(type);
   }
...
}

Is there a way I can specify an order-of-evaluation in Jersey so that it checks MySubClassMessageBodyReader before MyBaseClassMessageBodyReader?

If there is a way, is it only available in Jersey2? We're in the middle of transitioning from Jersey1 to Jersey2 so we need to come up with solutions for both, even if the solutions are different.

Best regards,

Richard

Loading...