Getservletcontext () Ljavax/servlet/servletcontext;

Java.lang.NoSjavax.servlet.http.HttpServletRequest.getServletContext () Ljavax/servlet/servletcontext;

Java.lang.NoSjavax.servlet.http.HttpServletRequest.getServletContext () Ljavax/servlet/servletcontext;

A colleague's computer can run on the code, upload to the server there was an error. Help colleagues to debug a mistake, a little share to everyone ~ ~ If you have the above mistakes, hope to help you
First, the error message is as follows:
The 1.0 error code is as follows:

Serious: Servlet.service () for Servlet Springmvc threw exception
Java.lang.NoSuchMethodError: Javax.servlet.http.HttpServletRequest.getServletContext () Ljavax/servlet/servletcontext;
    At Com.fh.controller.store.StoreController.upload (storecontroller.java:402) at
    Sun.reflect.NativeMethodAccessorImpl.invoke0 (Native method) at
    Sun.reflect.NativeMethodAccessorImpl.invoke ( Unknown source) at
    Sun.reflect.DelegatingMethodAccessorImpl.invoke (Unknown source)
    at Java.lang.reflect.Method.invoke (Unknown Source)

2 Click the wrong information

String path2 = Request.getservletcontext (). Getrealpath ("/");

Second, the error is explained as follows:
(1) Overall, it is your Java container (perhaps Tomcat) with the API specification is not 3.0, or Tomcat version is too low, and did not achieve the 3.0 specification. Look at the version of the package that Tomcat Servlert-api.jar with Lib.
(2) How to verify it. To Tomcat–>lib–> unpack Jsp-api.jar and servlet-api.jar–> unpack folders –>meta-inf–> with Notepad: MANIFEST.MF files
After the decompression of the information is as follows: A look is their version is too old to see more detailed information. The screenshot below is Tomcat6 's own Servlet-api.jar bag.

(3) Here decompression tomcat7 about the above two packages version information

manifest-version:1.0
ant-version:apache Ant 1.8.4
CREATED-BY:1.6.0_45-B06 (Sun Microsystems Inc.)
x-compile-source-jdk:1.6
x-compile-target-jdk:1.6

name:javax/servlet/jsp/
Specification-title:java API for JavaServer Pages
 //version information
specification-version:2.2 
Specification-vendor:sun Microsystems, Inc.
implementation-title:javax.servlet.jsp
implementation-version:2.2.fr
Implementation-vendor:apache Software Foundation

manifest-version:1.0
ant-version:apache Ant 1.8.4
CREATED-BY:1.6.0_45-B06 (Sun Microsystems Inc.)
x-compile-source-jdk:1.6
x-compile-target-jdk:1.6

name:javax/servlet/
Specification-title:java API For Servlets
 //version information
specification-version:3.0
Specification-vendor:sun Microsystems, Inc.
Implementation-title:javax.servlet
implementation-version:3.0.fr
Implementation-vendor:apache Software Foundation

You see, TOMCAT7 's Jsp-api is only a 2.2 version. The TOMCAT6 version is far too low. It is estimated that the Jsp-api version of TOMCAT8 is 3.0 and above.

Third, the solution
1.0 Many of the solutions on the web are to replace the jar package and promote a later version of the jar package. For example: Copy the TOMCAT8 version of Jsp-api to replace the original jar package. Or download the latest Jar pack
"Hint": I personally do not want to solve this. Don't forget that my Tomcat version is 6.0, replacing the high version of Jsp-api.jar. I do not know if there will be some use of JSP new features of the method of my tomcat6 have requirements. It's hard to find out. After the replacement of the high version of the jar pack is completely able to run the ~ ~ Test can be.
2.0 The problem is in the new writing, the original purpose of the code is to get the project root path. Change to the old version of the wording can be

From the original
String path2 = Request.getservletcontext (). Getrealpath ("/");
Change to
String path2 = Request.getsession (). Getservletcontext (). Getrealpath ("/");

And then the problem is solved perfectly.

I found out that my colleague was using JDK8+TOMCAT8. In this way his local project is completely free of problems. But there was a problem with my lower version of the TOMCAT6. Here's a little piece of advice. Personally suggest that your web development environment be synchronized with your company. In terms of the above example. If the company uses tomcat7+jdk1.7. You use tomcat6+jdk1.6 to run tomcat7+jdk1.7 project, the project may appear some tomcat6+jdk1.6 not new features. And if you use tomcat8+jdk1.8 environment to run the company project, you should be no problem local, tomcat1.8+jdk1.8 will be backward-compatible, perfect transition. But when you upload the code to the server, tomcat7+jdk1.7 is prone to errors if it is not compatible. Just like the mistake above.