DispatcherServlet, InstantiationAwareBeanPostProcessorAdapter, and Custom Argument Resolvers, using

Mark Determan

After updating some Cobalt code from Spring 3.0.7 to Spring 3.1.2, the DispatcherServlet is now requiring a default constructor for some classes in the Cobalt app. Without posting the code, here is a general summary ... The Spring configuration, the DispatcherServlet, and the bean post-processing have been updated to use RequestMappingHandlerAdapter. Somewhere in the internals of the DispatcherServlet, the bean-instantiation is requiring no-argument constructors for classes required by the servlet requests. My question is ... I am looking for a guru familiar with DispatcherServlet and SpringMVC (in Spring version 3.1.2).

Mark Determan

This was solved on 19 December 2012. There were several things involved:

(a) Updating the spring xml files to use version 3.1 of the schemas rather than version 3.0

(b) With Spring MVC 3.1, we ended up using "SecurityRequestParametersArgumentResolver extends HandlerMethodArgumentResolver". The previous solution for Spring 3.0 was "SecurityRequestParametersArgumentResolver extends WebArgumentResolver".

(c) We changed SecurityRequestParametersArgumentResolver to have only a no-argument constructor. The constructor arguments were moved to setter/getter methods, using Spring xml files for property-injection.