SPRINGMVC 4.3,requestparammethodargumentresolver Unable to resolve string parameter problems correctly

When building a new project, you want to use the latest stable version of the SPRINGMVC, so choose the latest version

            <dependency>                <groupId>org.springframework</groupId>                <ARTIFACTID>SPRING-WEBMVC </artifactId>                <version>4.3.1.RELEASE</version>                <exclusions>                    <exclusion >                        <groupId>commons-logging</groupId>                        <artifactid>commons-logging</artifactid >                    </exclusion>                </exclusions>            </dependency>

　　

And then wrote a very simple controller method with previous experience.

    @ResponseBody    @RequestMapping (value = "/cates") public    Object Cates (@PathVariable Long pageId, @PathVariable Long ModuleID,                        String goodids, Goods Goods) {        map<string,object> Map = new hashmap<string, object> () ;        Map.put ("1", "1");        return map;    }

　　

However, strange things have happened.

Parameter: http://localhost:8088/1/2/cates.json?goodIds=2,3

The runtime goodids is always null, and if parsing with the bean attribute is normal, that is, goods.goodids can parse normally.

My first thought was to add requestparam annotations to Goodids.

@ResponseBody    @RequestMapping (value = "/cates") public    Object Cates (@PathVariable Long pageId, @PathVariable Long ModuleID,                        @RequestParam (value = "Goodids", required = False) String Goodids, Goods Goods) {        Map<string,ob ject> map = new hashmap<string, object> ();        Map.put ("1", "1");        return map;    }

　　

So try, or not, on-line simple search of information, and did not search this situation, can only break point to see where the problem.

Because spring-mvc.xml inside, I wrote dead. Use Requestmappinghandleradapter to handle method-level related operations. Into this class, there is an implementation of the spring initialization object interface

@Overridepublic void Afterpropertiesset () {//Do this first, it may add responsebody advice Beansinitcontrolleradvicecache (); if (this.argumentresolvers = = null) {list
　　
You can see clearly that the Getdefaultargumentresolvers () method is the default parameter parser.
/** * Return The list of argument resolvers to use including built-in resolvers * and custom resolvers provided via {@link #setCustomArgumentResolvers}. */private list
　　
The entire code of the method is not truncated here, so we focus on
Requestparammethodargumentresolver
This parser, because the code level is too deep, interested students can break the point of their own step-by-step walk, in short, finally can come here to multipartresolutiondelegate.
Ispartcollection is a method parameter used to determine whether a parameter is associated with a file upload.
private static Boolean ispartcollection (Methodparameter methodparam) {return (Servletpartclass = = Getcollectionparametertype (Methodparam));} private static class<?> Getcollectionparametertype (Methodparameter methodparam) {class<?> ParamType = Methodparam.getnestedparametertype (); if (Collection.class = = Paramtype | | List.class.isAssignableFrom (Paramtype)) {class<?> ValueType = Genericcollectiontyperesolver.getcollectionparametertype (Methodparam); if (valueType! = null) {return valueType;}} return null;}
　　
Since Goodids is a string object, the return of the Getcollectionparametertype method is undoubtedly null, and the final Ispartcollection method returns True, which is no doubt unacceptable to us. For a fine reason, we will find that the Servletpartclass value is null and therefore returns TRUE.
And look at how it's initialized.
/** * A Common delegate for {@code Handlermethodargumentresolver} implementations * which need to resolve {@link Multipart File} and {@link part} arguments. * * @author Juergen hoeller * @since 4.3 */public abstract class Multipartresolutiondelegate {public static final Object U nresolvable = new Object ();p rivate static class<?> Servletpartclass = null;static {try {servletpartclass = Classutil S.forname ("Javax.servlet.http.Part", MultipartResolutionDelegate.class.getClassLoader ());} catch (ClassNotFoundException ex) {//Servlet 3.0 Javax.servlet.http.Part type not available-//part references simply no T supported then.}}
　　
It should be noted that the multipartresolutiondelegate is spring-web in the 4.3 version, so in some of the lower version of the SPRINGMVC, we are not sure to reproduce the problem, see how the framework implementation.
From here you can see that Servletpartclass is an object of type Javax.servlet.http.Part. And the catch block is clearly annotated.
Javax.servlet.http.Part is an object supported by Serlvet 3.0, so to Servletpartclass is not NULL, Should use serlvet3.0 version dependency, so my head is hot, right now SERLVET-API upgraded from 2.5 to 3.0.1
  <dependency>                <groupId>javax.servlet</groupId>                <artifactid>javax.servlet-api </artifactId>                <version>3.0.1</version>                <scope>provided</scope>            </ Dependency>
　　
Now, inside the IDE, you can search for the class Javax.servlet.http.Part and restart the project, however, Servletpartclass is still null and strong null.
Immediately, I remember, start the project with Tomcat6, rushed to think Tomcat6 might not support serlvet3.0 specification.
Tomcat official website http://tomcat.apache.org/whichversion.html page of the TOMCAT7 description, there is such a passage
Apache Tomcat 7.xApache Tomcat 7.x builds upon the improvements made Intomcat 6.0.x and implements the Servlet 3.0,jsp 2.2 , EL 2.2 andweb Socket 1.1 specifications. In Additionto that, it includes the following improvements:web application memory leak detection and preventionimproved SE  Curity for the manager and Host manager applicationsgeneric CSRF protectionsupport for including external content directly In a Web applicationrefactoring (connectors, lifecycle) and lots of internal code Clean-upapache tomcat 6.xApache Tomcat 6.x builds upon the improvements made Intomcat 5.5.x and implements the Servlet 2.5 andjsp 2.1 specifications. In addition to, it includes thefollowing improvements:
　　
tomcat7.x Support serlvet3.0 specification, and TOMCAT6 does not support, download TOMCAT7, after the application, Servletpartclass is not NULL, finally oh, successfully acquired to Goodids
Summarize:
Many new classes are added to the 1.springmvc 4.3 version, such as Multipartresolutiondelegate, which are implemented based on the Servlet 3.0 specification. If you use the old serlvet2.5 specification, it doesn't work, and Tomcat needs to support serlvet3.0 at the same time, and the minimum version of Tomcat needs to be 7.x.
2. In fact, when looking at the MAVEN version of spring mvc 4.3 dependency, there is this dependency
<dependency>      <groupId>javax.servlet</groupId>      <artifactid>javax.servlet-api </artifactId>      <version>3.0.1</version>      <scope>provided</scope>    </ Dependency>
It is not written to play, which means that, to use spring mvc 4.3, you should use the SERLVET3.0 specification, tomcat using at least 7.x
The 3.MultipartResolutionDelegate itself is an abstract class used to parse the method parameters that determine the Multipartfile and part types, and if you cannot get to the part type object, you cannot properly perform the functions it should have. In the use of new tools or versions, it is inevitable that there will be incomprehensible things, find the reason, the analysis of the solution will have a sense of the enlightened
SPRINGMVC 4.3,requestparammethodargumentresolver Unable to resolve string parameter problems correctly