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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Grzegorz
Hi Lenny,
I'm sorry... a lot of time has passed since my email, but I was extremely busy through the last 6 months. And I'm still, so it's probably gonna be my last answer.


> Weld+Anything is going to be more and more common

My observations are different. With all flaws of the Java EE platform, I expect it to be less and less popular over time.
P.S. I know it's not a very good argument, but please take a look at the combined number of the StackOverflow posts tagged with cdi/ deltaspike/ java-ee/ ejb (~60 per week) and compare it with, let's say a Spring (~470 per week). It's not a small difference - it's order of magnitude. And the trend stays the same for a long time.
Disclaimer: I'm not, and I've never been a Spring's fan - I usually prefer Guice when doing a simple DI.


> 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.

With all due respect to Weld's authors, I cannot agree with "very, very solid now". I'm not an expert, but after 1,5 years of its use, my personal opinion is opposed.
And I think it will never be "rock solid", because the core concept behind a CDI is an excessive class path scanning and automatic configuration based on its findings. I find it cumbersome and brittle.


> Any integration will have it’s beginning growing pains

Sorry, but Weld and Jersey integration is ~4 years old. I cannot call it 'beginning'.


To give some concrete arguments, below are some of the problems I've encountered.

1. Core idea behind CDI is an excessive class path scanning. CDI configure itself based on what it finds during class path scanning. It is very cumbersome and fragile, especially in situations like: unit tests, running from IDE on the exploded archive, uber-jars etc.
2. Class path scanning and implicit configuration is not only brittle & error prone but also not much configurable (without tricks/ hacks).
3. All alternatives, interceptors and decorators are selected/enabled per bean archive by using a beans.xml descriptor. Very unintuitive.
4. It's extremely easy to misuse CDI annotations, but none warning will be ever printed. Annotations are everywhere, but their validation is poor.
5. @Alternatives work fine as far as you are injecting in the same isolation level (jar/war). But each jar having its own beans.xml has its own rules of injecting. So it is not possible to control what is injected in the lower level (jar) while being in another jar.
6. @Alternative has a trap:  its javadoc documentation lies, it cannot be applied to methods. Because the `beans.xml` accepts only two kind of entries: `<stereotype>` and `<class>` - there is no way to type there method or field. Another thing, take a look at the Weld Doc, Chapter 13.2 titled - 'A minor problem with alternatives'.
7. @Specializes never worked for me. It has been skipped without any warnings. After 5 hours of reading CDI specification and trying various approaches I've failed to make it work. My fault? It might be.
8. Many counter-intuitive behaviors, Issue CDI-408 is only an example. There are plenty of others.
9. Since Java EE 7, literally all archives can became accidentally a CDI archive, even without any beans.xml file. Awkward.
10. When starting Weld in unit tests, Weld container treated classes from `classes` and from `test-classes` as separated beings. Thus while running tests from the second location, classes from the first weren't visible. It's gone now, but it hasn't been fixed until mid 2014. Madness. (again, another issue caused by a class-path scanning)

And finally, a funny thing: CDI 1.x was so strongly focused on Java EE - that prior CDI 2.0, its behavior hasn't been even defined outside of a Java EE container. Fortunately Weld's authors enabled us to do it.

DISCLAIMER: I have no intention to start here any flame war about Weld vs Spring vs Guice vs Anything. Above I've only summarized the personally encountered problems with a CDI/ Weld over the last 1,5 year. Anyone might have a different experience and I respect it.

That's all from my personal feelings. Forgive me a long mail !

Regards,
Greg


2016-08-11 18:37 GMT+02:00 Lenny Primak <[hidden email]>:
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
|

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

Lenny Primak
Wow, that devolved quickly.
If you like Spring, Congratulations!  Use it and be happy.  It’s your opinion, it’s valid to you, and that’s great.

My opinion, on the other hand, is mine, is also valid.  Questions on StackOverflow isn’t a measure of success of the platform.
The opposite is true, in my opinion, actually.
Sprint never worked out of the box for me, and Java EE has, so that’s my take.


On Jan 6, 2017, at 1:11 PM, Grzegorz <[hidden email]> wrote:

Hi Lenny,
I'm sorry... a lot of time has passed since my email, but I was extremely busy through the last 6 months. And I'm still, so it's probably gonna be my last answer.


> Weld+Anything is going to be more and more common

My observations are different. With all flaws of the Java EE platform, I expect it to be less and less popular over time.
P.S. I know it's not a very good argument, but please take a look at the combined number of the StackOverflow posts tagged with cdi/ deltaspike/ java-ee/ ejb (~60 per week) and compare it with, let's say a Spring (~470 per week). It's not a small difference - it's order of magnitude. And the trend stays the same for a long time.
Disclaimer: I'm not, and I've never been a Spring's fan - I usually prefer Guice when doing a simple DI.


> 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.

With all due respect to Weld's authors, I cannot agree with "very, very solid now". I'm not an expert, but after 1,5 years of its use, my personal opinion is opposed.
And I think it will never be "rock solid", because the core concept behind a CDI is an excessive class path scanning and automatic configuration based on its findings. I find it cumbersome and brittle.


> Any integration will have it’s beginning growing pains

Sorry, but Weld and Jersey integration is ~4 years old. I cannot call it 'beginning'.


To give some concrete arguments, below are some of the problems I've encountered.

1. Core idea behind CDI is an excessive class path scanning. CDI configure itself based on what it finds during class path scanning. It is very cumbersome and fragile, especially in situations like: unit tests, running from IDE on the exploded archive, uber-jars etc.
2. Class path scanning and implicit configuration is not only brittle & error prone but also not much configurable (without tricks/ hacks).
3. All alternatives, interceptors and decorators are selected/enabled per bean archive by using a beans.xml descriptor. Very unintuitive.
4. It's extremely easy to misuse CDI annotations, but none warning will be ever printed. Annotations are everywhere, but their validation is poor.
5. @Alternatives work fine as far as you are injecting in the same isolation level (jar/war). But each jar having its own beans.xml has its own rules of injecting. So it is not possible to control what is injected in the lower level (jar) while being in another jar.
6. @Alternative has a trap:  its javadoc documentation lies, it cannot be applied to methods. Because the `beans.xml` accepts only two kind of entries: `<stereotype>` and `<class>` - there is no way to type there method or field. Another thing, take a look at the Weld Doc, Chapter 13.2 titled - 'A minor problem with alternatives'.
7. @Specializes never worked for me. It has been skipped without any warnings. After 5 hours of reading CDI specification and trying various approaches I've failed to make it work. My fault? It might be.
8. Many counter-intuitive behaviors, Issue CDI-408 is only an example. There are plenty of others.
9. Since Java EE 7, literally all archives can became accidentally a CDI archive, even without any beans.xml file. Awkward.
10. When starting Weld in unit tests, Weld container treated classes from `classes` and from `test-classes` as separated beings. Thus while running tests from the second location, classes from the first weren't visible. It's gone now, but it hasn't been fixed until mid 2014. Madness. (again, another issue caused by a class-path scanning)

And finally, a funny thing: CDI 1.x was so strongly focused on Java EE - that prior CDI 2.0, its behavior hasn't been even defined outside of a Java EE container. Fortunately Weld's authors enabled us to do it.

DISCLAIMER: I have no intention to start here any flame war about Weld vs Spring vs Guice vs Anything. Above I've only summarized the personally encountered problems with a CDI/ Weld over the last 1,5 year. Anyone might have a different experience and I respect it.

That's all from my personal feelings. Forgive me a long mail !

Regards,
Greg


2016-08-11 18:37 GMT+02:00 Lenny Primak <[hidden email]>:
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