The Method Getdispatchertype() Is Undefined for the Type Httpservletrequest

getDispatcherType() is undefined for the type HttpServletRequest

I had the same issue when I had a conflicting servlet-api version I was using in IntelliJ that conflicted with what was supported in Tomcat 8.0.x... I was using Maven, so I just changed my dependency to this, then did a clean deploy of my webapp and the problem went away.

<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>

The method getDispatcherType() is undefined for the type HttpServletRequest

My code has worked. The changes I made are:

  1. I changed the version of my javax-servlet-api from 2.3 to 3.1
  2. I changed the showHello method of my Controller Class to this:

    @RequestMapping(value = "/student", method = RequestMethod.GET)
    public ModelAndView showHello(Model model) {
    System.out.println("This is showHello method.");
    return new ModelAndView("student", "command", new Student());
    }

Basically, what I did is, I changed the argument of the method from ModelAndView to Model.

Struts: The method getDispatcherType() is undefined for the type HttpServletRequest

ServletRequest.getDispatcherType() was defined in Servlet 3.0 API.

The error indicates that you are either running the application with an older version of the Servlet API or that your application includes an servlet jar which is imcompatible with your runtime.

Since you are running Tomcat 8.0 I would check if your app includes jar files which contain an older servlet version.

spring 4.1 giving error when a new project is created

If you were to google your error message The method getDispatcherType() is undefined for the type HttpServletRequest you'd find this answer to your problem.

Learning Spring with Spring in Practice book, getting exception org.apache.jasper.JasperException:, while executing recipe 4.1

I am answering my own questions because I ended up finding the solution, so if someone else finds this problem again here it goes:

The WebApp does not run directly in Tomcat v8.0 due to the error of the question. In Tomcat v6.0 gives error Unable to read TLD “META-INF/c.tld” from JAR file.

The solution is running it in Jetty and then the correct address to point is http://localhost:8080/sip/users/new.html

The type getServletContext() is undefined for the type HttpServletRequest in a maven project for Eclipse

Solution

Replace :

<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>

with

</dependency>
</groupId>`org.mortbay`.jetty</groupId>
</artifactId>servlet-api</artifactId>
</version>3.0.20100224</version>
</dependency>

Differenct between org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1

Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.

Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.

Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.

Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:

  • http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom

These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.



Related Topics



Leave a reply



Submit