Default Dropwizard-added ExceptionMappers to be configurable

[kschulst]

Dropwizard by default adds jersey exception mappers. There have been various discussions related to how these can be disabled, like:
https://groups.google.com/forum/#!searchin/dropwizard-user/exception$20mappers/dropwizard-user/CgPjcY4SLFg/xSDzOCvyx0gJ

A workaround is described here:
http://thoughtspark.org/2013/02/25/dropwizard-and-jersey-exceptionmappers/

This all worked great with jersey 1. However, with jersey 2 there are no way (that I have found) to "deregister" exception mappers once they have been registered. The jersey provider singletons (in org.glassfish.jersey.server.ResourceConfig) are wrapped in an unmodifiable Set which results in an exception being thrown if attempting to use the approach referenced above.

The motivation for removing/overriding dropwizard exception mappers can of course be debated, but we have currently been doing so in order to have full control over what is being used. Since the underlying jersey implementation uses a Set to hold the exception mappers and the iteration order of a Set cannot be guaranteed, then it has been the safest bet to just remove all dropwizard exception mappers to guarantee that our custom ones are being used.

Therefore, I propose a feature request: Make it possible in dropwizard configuraton to override the way exception mappers are being added.

Would it be interesting if I created a pull request for something like this? And if so, would it be possible to get this into the upcoming 0.8.0 relase if I move quickly?

[wirde]

FWIW - I would really like to have this ability too.

[bjorntorewiken]

+1

[mcarrierastonish]

+1, if you need a hand let me know.

[nottix]

+1

[wangyingang]

+1

[skjegg]

+1 . If Jersey 2 doesn't allow for unregistering exception mappers, yet retains the utterly broken un ordered Set implementation, it could make moving to 0.8 difficult for us.

[dbyron0]

Doesn't the code here: http://grepcode.com/file/repo1.maven.org/maven2/com.sun.jersey/jersey-server/1.17.1/com/sun/jersey/api/core/DefaultResourceConfig.java?av=f#62 mean that iterating mappers happens in a predictable/stable order? If so, then isn't the bug elsewhere? I still totally support being able to override the built-in mappers.

[joschi]

@dbyron0 The source code you've come up with is from Jersey 1.17.1. We're using Jersey 2.13 in Dropwizard 0.8.x.

[mikeycmccarthy]

+1

[cmicali]

+1 - This really needs to be configurable.

Here is my current hack solution for Jersey 2.x / dw 0.8:
https://gist.github.com/cmicali/2ee7b3b6941005dc5596

@joschi I'm happy to do this work but interested in your thoughts on how to make this configurable. There is no configuration going into Environment/JerseyEnvironment currently.

[GreyTeardrop]

The problem with exception mappers in Jersey 1.x is caused by ExceptionMapperFactory class, as it stores all exception mappers in HashSet and has unpredictable iteration order (even though complete set of singletons in DefaultResourceConfig has predictable ordering).

However, Jersey 2.x replaces that HashSet with LinkedHashSet. It might resolve exception mappers ordering issue for Dropwizard 0.8, but I haven't yet had a chance to check that.

[cmicali]

I made this configurable with pull request #793

I made this a configuration property on AbstractServerFactory so you just add the following to your server.yml

server:
    registerDefaultExceptionMappers: false

FWIW this is a blocking issue for us to migrate to 0.8

[mikeycmccarthy]

Great hack, cheers @cmicali . Will give that one a go today.

[cmicali]

@mikeycmccarthy It worked well enough for us to get going with the 0.8 transition, but beware the hack is not 100%. I think the DW exceptionmappers are still being cached somewhere and thanks to the non-deterministic set they are stored in 1 in 10 times they take precedence over your versions.

So, good enough to unblock development but not suitable for production. #793 is the "right" way to handle this.

[fzakaria]

Honestly why even have LoggingExceptionMapper ?
It seems like it can be replaced with a Filter and achieve the same functionality ?
See : https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/container/ContainerResponseFilter.html

Why don't we just remove it...

[vaamyob]

It's been 4 months since this issue was opened. I'm surprised @codahale hasn't responded, since overriding the default DW behavior seems like it would be one of the first things a new project would want to do. How else are you going to get ConstraintViolationExceptions to the client?