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
400 errors generated by a ValidationException are returning default error page instead of the Bean Validation's response entity #2945
Comments
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented Thanks for submitting the issue. I've just attached your github example to it. And I also edited your description a bit (so that links work etc.), hope you don't mind. The issue will be now moved to backlog and we will take a look at it in one of the future sprints. Regards, |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented As a workaround, I found the combination of these three obscure settings gave me back a REST response that is JSON and not the HTML error pages (at a somewhat high productivity cost.) Perhaps you have this flag set? In my view the error pages should be a result that is disabled, if you start the GrizzlyHttpServer in code, by default it should return whatever Jersey returns, not filter or alter the output with any HTML pages, simplifying this issue. Turning it on should be one flag. The most important, and not well documented of them, is setting the custom ErrorrPageGenerator, overriding the default Grizzly Error Page Generator. This is on Jersey = 2.21, Grizzly = 2.3.22.
1. Set an init parameter that is non-obvious "do what you should do by default"
2. Add an 'ErrorPageGenerator', overwriting the default Error Page Genenerator (now basically hacking into Jersey and Grizzly internals, to get it to return JSON errors for a REST Container?)
3. Return a Response object with Bad Request (which is the 400 code I want exposed to the users, not 200), with a custom object inside containing an error message property:
This seems like a decent size hack, to simply return the results of an Exception inside the server, as a 400/500 error + JSON error message. I tried working with custom exception mappers, but still Grizzly would resolve these to HTML 500 or HTML 400 error pages. Notably returning http response code 0 would surpass these pages, but 400 / 500 is the standard I needed to adhere to. Thanks for looking, hope it helps, Chris |
@glassfishrobot Commented |
@glassfishrobot Commented |
|
400 errors generated by a javax.validation.ValidationException are returning
(Grizzly's) default error page (html) instead of the Bean Validation's
response entity (json). I've tried a ClientResponseFilter and its entityStream
also contains the html error page.
I have put a test project up on github. I asked on Stackoverflow (http://tinyurl.com/o7oou85) and one of
the Grizzly guys says that this is Jersey's behaviour -
org.glassfish.jersey.message.internal.CommittingOutputStream#flushBuffer(boolean) - writes JSON error message to the Servlet OutputStream
and
org.glassfish.jersey.servlet.internal.ResponseWriter#commit() - if data has been written to the response buffer, but not returned to the client (i.e. the response is not committed), the data in the response buffer must be cleared and replaced with the data set by these methods ...
I would like some configuration setting that would allow choice between
the default error page or the Bean Validation's response entity.
Environment
GrizzlyHttpServerFactory + Jersey + Bean Validation (jersey-container-grizzly2-servlet/jersey-bean-validation ver 2.12, grizzly-http-server ver 2.3.16, hibernate-validator ver 5.0.0.Final)
Affected Versions
[2.13]
The text was updated successfully, but these errors were encountered: