-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExceptionMappers should be implemented by the users not by the library #53
Comments
I suggest you bring this up on mailing list -- for backwards compatibility, simple removal is not an option, there needs to be a graceful way to upgrade. Improvements to handling (especailly via pull requests) are welcome too of course. |
You should be able to unregister the Jackson ExceptionMappers in your Jersey configuration in the meantime. |
Thanks for your response, I will try to unregister the exception mapper if On 4 July 2014 12:05, Paul Brown [email protected] wrote:
|
Actually as far as I found in my research it is not possible to unregister On 5 July 2014 00:45, Ramiro Serrato [email protected] wrote:
|
I think this is dup of #22 |
Your exception mappers for json pasing and json mapping are shadowing my exception mappers which I use to produce an structured json error response, this kind of error handling should be done by the application that is using your library, otherwise you force the rest apis to follow your response messaging convention. I am using jersey 2.10 and my exception mappers are never picked up but yours com.fasterxml.jackson.jaxrs.base.JsonMappingExceptionMapper and com.fasterxml.jackson.jaxrs.base.JsonParseExceptionMapper.
The text was updated successfully, but these errors were encountered: