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
@ResponseBody usage limitations [SPR-7278] #11937
Comments
Rossen Stoyanchev commented For handling exceptions centrally I would recommend implementing HandlerExceptionResolver. Even though it's less convenient than As for assuming |
Gerrit Brehmer commented I searched for a way to minimize the use of the ModelAndView-concept. HandlerExceptionResolver depends on the concept and |
Rossen Stoyanchev commented The DefaultHandlerExceptionResolver is similar to your description. It translates exceptions into status codes and doesn't rely on view resolution and always returns an empty ModelAndView. Also we can consider an extension hook in the new ExceptionHandlerExceptionResolver, which would allows customizations to the list of protected void extendExceptionHandlerMethods(List<Method> methods, Class<?> handlerType) {
} A subclass of ExceptionHandlerExceptionResolver would then have a chance to add |
Rossen Stoyanchev commented The above mentioned extension method is now available. |
Gerrit Brehmer commented Thanks. I will check this out with the next version. |
Gerrit Brehmer opened SPR-7278 and commented
The recommended way to develop REST-style webservices is the usage of
@ResponseBody
annotation and HttpMessageConverter instead of generating a model and a view (ContentNegotiatingViewResolver etc.).But there are some limitations, that make things hard to handle:
@RequestBody
is only supported with@ExceptionHandler
annotation. I need a centralized exception handling to generate a special error object as the return value. So I must wrote a method in each controller class to delegate to the centralized exception handler. I think the ExceptionResolver-interface is more like an AOP-approach, with no glue code.@ExceptionHandler
out of the box@ResponseBody-like
handling instead of annotate all methods (e.g. in AnnotationMethodHandlerAdapter)I also would recommend the full HttpMessageConverter way (
@RequestBody
&@ResponseBody
) without view handling, so it would be nice, if@ResponseBody
has fewer limitations. Additionaly it would be great, if the documentation have some notes about the recommended way for webservice-only REST-style applications (with hints to the limitations above)Affects: 3.0.2
Issue Links:
@ExceptionHandler
doesn't handle exceptions from other controllers ("is duplicated by")@Produces
to Spring MVCReferenced from: commits e5eceaf
1 votes, 2 watchers
The text was updated successfully, but these errors were encountered: