jersey
jersey copied to clipboard
javaee
Add option to prevent registration of JsonParseExceptionMapper and JsonMappingExceptionMapper in jersey-media-json-jackson
Please provide an option to prevent the two Jackson mappers from registering. See the problem description : https://stackoverflow.com/questions/5833147/jersey-jackson-exception-problem-with-exceptionmapper (top voted answer).
Mappers are registered in https://github.com/jersey/jersey/blob/master/media/json-jackson/src/main/java/org/glassfish/jersey/jackson/JacksonFeature.java line 87 and 88.
Perhaps through an init parameter in web.xml or similar way.
At the moment there is simply no way to create your own exception mapper and expect jersey-media to respect it. It will randomly use the jersey defined mapper or your custom mapper, it changes from application run. Annotating custom mapper with @Priority does nothing, probably because jersey-media mappers are registered explicitely.
There used to be an issue with jackson library defining their own mapper beans but that was fixed upstream, so right now the last culprit is jersey-media.
The workaround in SO thread with excluding jersey-media and registering Jackson provider manualy works but I'd prefer using jersey-media but without the two mappers registered.
We need to think about more general approach that would prevent registering default providers, not only the mappers in this case.
+1
As-is the default behavior will leak internal classes.
In one concrete example that we've personally ran into, posting to a resource with an Integer-typed field and passing back a value that is out of range will produce the following response message:
[Cannot deserialize value of type java.lang.Integer from String "2147483648": Overflow: numeric value (2147483648) out of range of Integer (-2147483648 - 2147483647) at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 1, column: 201] (through reference chain: path.to.our.class["someField"])]
We can create our own json exception mapper handler, but, like the original poster explained, there is no way to get jersey to respect which one is used so the only viable alternative is to avoid JacksonFeature altogether (which is what the documentation suggests you use). We could also potentially modify our object mapper resolver but that feels at odds with the intent of exception mappers.
