@RequestMapping methods returning null have an implicit ModelAndView created [SPR-4518]

[spring-projects-issues]

Chris Lee opened SPR-4518 and commented

It isn't clear that this is necessarily a bug.

When annotating a 'void' method with @RequestParam, and that method does not take the Response (or any output construct therein, i.e. PrintWriter), an implicit ModelAndView is created in AnnotationMethodHandlerAdapter. In the case where there was no intent to have a MAV returned (and hence no view resolvers were configured), this results in a circular view path error (stack trace below). The method definition looks like:
@Controller
@RequestMethod(value="/BCMinistryBillingServer/*,method=RequestMethod.POST)
public class TestMethod {
@RequestParam
public void handleBill( @RequestParam("data") String data )
{
// some code here
}
}

In this case, there is no return value and the method does not write anything back - nor is anything expected back in the response body (it is a system interface).

09:04:19,990 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Invoking afterPropertiesSet() on bean with name 'handleBill'
09:04:19,990 DEBUG [org.springframework.web.servlet.view.InternalResourceViewResolver] Cached view [handleBill]
09:04:19,990 DEBUG [org.springframework.web.servlet.DispatcherServlet] Rendering view [org.springframework.web.servlet.view.JstlView: name 'handleBill'; URL [handleBill]] in DispatcherServlet with name 'springDispatcherServlet'
09:04:19,990 DEBUG [org.springframework.web.servlet.view.JstlView] Rendering view with name 'handleBill' with model {} and static attributes {}
09:04:20,006 DEBUG [org.springframework.web.servlet.DispatcherServlet] Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@ee50b4
09:04:20,006 DEBUG [org.springframework.web.servlet.DispatcherServlet] Could not complete request
09:04:20,022 ERROR [[springDispatcherServlet]] Servlet.service() for servlet springDispatcherServlet threw exception
javax.servlet.ServletException: Circular view path [handleBill]: would dispatch back to the current handler URL [/BCMinistryBillingServer/handleBill] again. Check your ViewResolver setup! (Hint: This may be the result of an unspecified view, due to default view name generation.)
at org.springframework.web.servlet.view.InternalResourceView.prepareForRendering(InternalResourceView.java:261)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:192)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:252)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1162)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:900)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:808)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:523)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:463)

---

Affects: 2.5.2

Referenced from: commits 6fbd198

1 votes, 2 watchers

[spring-projects-issues]

Juergen Hoeller commented

Indeed, this is arguably an undesirable side effect of the default view name resolution convention. It's arguably an indicator for the general pitfalls of convention-based programming: You might accidentally have the convention applying without it being intended or without you even being aware of the convention in the first place.

We'll revisit this for 2.5.3. One solution would be to indicate that this is a sort of one-way method through an annotation - or to indicate the HTTP status code to send back. After all, the calling client needs to have something returned, even if just a 200 OK. This is why I would presently declare an HttpServletResponse argument and call setStatus(SC_OK) in such a case.

Juergen

[spring-projects-issues]

Chris Lee commented

Agreed, this does pose some challenges. We've presently declared an HttpServletResponse argument, though it is unused (to match the previous Servlet based implementation) - will likely rework to make the response clearer.

[spring-projects-issues]

Juergen Hoeller commented

This is likely going to remain as-is for the 2.5.x branch, to be generally revisited for Spring 3.0 where we are considering related functionality for Portlet request mappings (avoiding the need for declaring an ActionResponse argument just to set render parameters).

Juergen

[spring-projects-issues]

Arjen Poutsma commented

You can now annotate a method with @ResponseStatus, like so:

@RequestMapping("/something")
@ResponseStatus(HttpStatus.CREATED)
public void handle() throws IOException {
}

This will set the response status code to 201, and not fall activate to the default view name resolution.