We Keep Coding

The method getDispatcherType() is undefined for the type HttpServletRequest

When I run my applicaiton from Eclipse it runs without any errors for servlet api 3.1.0 and 3.0.1.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
I use tomcat 8.0.21 for eclipse. I have set up tomcat8 on ubuntu machine which runs on tomcat 8.0.14 stable version.
Unfortunately, I get the following error message if I use servlet api 3.1.0. But it works for the older version 3.0.1.
root cause
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: [50] in the generated java file: [/var/lib/tomcat8/work/Catalina/localhost/ROOT/org/apache/jsp/WEB_002dINF/view/templates/login_002dtemplate_jsp.java]
The method getDispatcherType() is undefined for the type HttpServletRequest
Stacktrace:
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:103)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:199)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:450)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
Why do I get this error? How to fix this?

You're not supposed to provide Servlet API along with the web application archive if the target runtime already provides the API out the box. Tomcat as being a JSP/Servletcontainer already provides JSP, Servlet and EL APIs out the box. When you provide them along with your webapp anyway, then you may run into classloading conflicts caused by duplicate different versioned classes in the runtime classpath coming from both the webapp and the server.
Add <scope>provided</scope> to those dependencies already provided by the target runtime.
See also:
How do I import the javax.servlet API in my Eclipse project?

For Maven users there are several good answers here that you might want to check out.
I'm still in the dark ages, and am not using a dependency manager for my Tomcat project. If you're like me and have this issue, here's how I solved it: It seems tomcat provides the javax.servlet classes, so these don't need to be in your project's lib file. (I originally had the servlet-api-2.5.jar in my /WEB-INF/lib directory.) However you'll probably still need it to compile (I did), so you should move it to a location included in your java classpath. You may also need to tell your IDE where to look.
Hope that helps.

Method ServletRequest#getDispatcherType() was introduced to the Servlet Spec since version 3.0. The following error means that you are using an older version (e.g., 2.5) of javax.servlet-api in your application.
The method getDispatcherType() is undefined for the type HttpServletRequest
To solve this issue, you could follow the following two steps:
First of all, add <scope>provided</scope> to dependency javax.servlet-api
You should add <scope>provided</scope> to the dependency, because your Tomcat container will provide the dependency at runtime. And at the same time, ensure that you are using Tomcat 7 or higher, which supports Servlet Spec 3.0 or higher.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
Second of all, exclude any older version of javax.servlet-api
You need to ensure that any older version (e.g., 2.5) of javax.servlet-api is not included transitively. You can use mvn dependency:tree to find out. See below an example:
$ mvn dependency:tree
...
[INFO] +- com.google.oauth-client:google-oauth-client-servlet:jar:1.20.0:compile
[INFO] | +- com.google.oauth-client:google-oauth-client:jar:1.20.0:compile
[INFO] | +- com.google.http-client:google-http-client-jdo:jar:1.20.0:compile
[INFO] | +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] | \- javax.jdo:jdo2-api:jar:2.3-eb:compile
[INFO] | \- javax.transaction:transaction-api:jar:1.1:compile
...
In this case, javax.servlet-api version 2.5 is included transitively by a dependency called google-oauth-client-servlet. We need to exclude it in pom.xml, like below:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-servlet</artifactId>
<version>1.20.0</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
That's it.

SonarQube "Class Not Found" during Main AST Scan

My setup:
Sonarqube 5.1.1
Sonar-Maven Plugin 2.6 (also tried 2.7 and 3.6)
JDK 1.7.0_51
Example of the error:
16:00:54 [INFO] [23:00:54.219] Sensor JavaSquidSensor
16:00:55 [INFO] [23:00:55.030] Java Main Files AST scan...
16:00:55 [INFO] [23:00:55.030] 1532 source files to be analyzed
16:00:58 [ERROR] [23:00:57.927] Class not found: javax.annotation.Nullable
16:00:58 [ERROR] [23:00:57.928] Class not found: javax.annotation.CheckReturnValue
16:00:58 [ERROR] [23:00:58.114] Class not found: javax.annotation.Nullable
According to this stackoverflow question, javax.annotation should be part of java 1.7 and up. Furthermore, I've tried putting it in the local maven repository but that didnt help.
So where is Sonar trying to find this package? Any help?!?
Update:
I've tried modifying the sonar-maven-plugin to include a dependency on javax.annotation
I've tried putting the dependency in my maven's settings.xml
Upgrading my JDK to 1.8 has not helped.

According to http://docs.oracle.com/javase/7/docs/api/index.html?javax/annotation/package-summary.html the classes you expect are not part of JDK 7.
The classes you're looking for are part of google JSR-305 implementation that was initiated here https://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/Nullable.java?r=24 and which moved to Findbugs:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>3.0.0</version>
</dependency>
According to https://jcp.org/en/jsr/detail?id=305 the JSR-305 is finished, but is in dormant status and has not been added to a JDK release yet.
Hope it helps.

To avoid adding SonarQube specific dependencies to your project, define a profile like this:
<profile>
<id>sonarqube</id>
<dependencies>
<dependency>
<groupId>org.joda</groupId>
<artifactId>joda-convert</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>3.0.0</version>
</dependency>
</dependencies>
</profile>
Then run your sonar analysis with a command like
mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.1:sonar -Psonarqube,sonarqube-dev
The sonarqube-dev profile is defined in my ~/.m2/settings.xml and it just specifies where my development environment SonarQube installation is
<profile>
<id>sonarqube-dev</id>
<properties>
<!-- no direct db connections in new sonar -->
<sonar.host.url>
http://localhost:9000/
</sonar.host.url>
</properties>
</profile>
What is achieved by all this?
sonarqube analysis specific dependencies don't pollute the project unnecessarily
no sonarqube maven plugin defined in pom.xml. Each developer and Jenkins can use whatever sonar plugin and server installation they wish

This is more an addendum to the latest answer:
I see similar problems and adding the google findbugs dependency to the project dependencies helps. Similar problems occured with joda convert like
[ERROR] [20:44:25.247] Class not found: org.joda.convert.ToString
Hence I also added
`<dependency>
<groupId>org.joda</groupId>
<artifactId>joda-convert</artifactId>
<version>1.8.1</version>
<scope>provided</scope>
</dependency>`
But note, that I set the scope to provided to prevent these new dependencies to be added to a resulting war file.
However, I still wonder why these errors occur since none of the analyzed classes seem to use these annotations?

Build Failure in Jenkins, Found duplicate resources

I recently added this dependency to pom.xml
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
</dependency>
My builds are failing in jenkins with the following error message:
[WARNING] Found duplicate resources in [org.codehaus.groovy:groovy:2.3.7,org.codehaus.groovy:groovy-json:2.3.7,org.codehaus.groovy:groovy-xml:2.3.7] :
[WARNING] META-INF/groovy-release-info.properties
[JENKINS] Archiving disabled
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:37.485s
[INFO] Finished at: Mon Mar 09 10:10:49 PDT 2015
[INFO] Final Memory: 46M/381M
[INFO] ------------------------------------------------------------------------
[JENKINS] Archiving disabled
Waiting for Jenkins to finish collecting data
[ERROR] Failed to execute goal com.ning.maven.plugins:maven-duplicate-finder-plugin:1.0.4:check (default) on project LightmileTest: Found duplicate classes/resources -> [Help 1]

Background/Details
I had a similar issue and this threw me for a loop for a while and I started to question my maven knowledge and did some digging. If you want to learn more about duplicate finder, you can read the readme on their github: https://github.com/ning/maven-duplicate-finder-plugin
For the project I was on, I determined I could do excludes in the dependencies or add exceptions to the duplicate finder. I saw both in my project and wondered when it was appropriate to do which.
The message from the plugin helps identify where duplication resides. You'll normally see this when you try to add new dependencies. When you see that, there are two options, either exclude things from the dependencies, or create exceptions in your com.ning.maven.plugins:duplicate-finder-maven-plugin configuration.
Summary / Conclusion
Adding an exception, just ignores the problem. So the cleaner way is add the excludes in the dependencies. This way you get exactly what you expect/desire. Furthermore, going down the exception route would just add a ton of extra work that isn't really useful. So the intent of the plugin is to help you identify duplications, then try to handle them via excludes in the dependencies.
Example of How to Do Exclude
In your example/case, one of the following should work for you:
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-json</artifactId>
</exclusion>
</exclusions>
</dependency>
or
<dependency>
<groupId>com.jayway.restassured</groupId>
<artifactId>rest-assured</artifactId>
<version>2.4.0</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
</exclusion>
</exclusions>
</dependency>

It is likely that your new dependency is failing on this test your are doing via Maven (duplicate-finder-plugin). Run the manual check from command line (on the level of the POM file) to find out what are the offending classes:
mvn com.ning.maven.plugins:duplicate-finder-maven-plugin:1.0.4:check
Then you can either remove the dependency or configure the Maven plugin to ignore these. (config here)

dependency:analyze-duplicate Analyzes the and tags in the pom.xml and determines the duplicate declared dependencies.
mvn dependency:analyze-duplicate

What you can do is to follow the rule of scope, meaning that, separate dependencies according to their scopes, such as in your case, rest assured used for testing, why not to put it under the scope of a test:
<scope>test</scope>
Secondary, what I usually do is executing exactly same commands from Jenkins on my local machine and usually it does help, from you error log I think it is not rest assured related, so please try to run MVN goal which is on Jenkins side locally and make sure you have the same error. If not, it can be a different configuration of maven for example via settings.xml in Jenkins machine.

Use to avoid the duplicate finder.

unexpected exception: java.lang.NoClassDefFoundError: org/apache/log4j/LogManager

I'm developing a GWT application. It's using RPC to collect information from an internal system. It does so by using a library jar, lets call it alpha.jar. We are using this jar in many application so it works fine, and btw its built with ANT, outside eclipse.
Some classes in alpha.jar references LOG4J2 and also lots of other external jars, so when we run an application we pass a classpath to all those, and everything works out fine. Please note that this is not a simple beginners problem. The alpha.jar is working as it should, including calls to Log4J.
The problem:
In Eclipse, I have this GWT application project and also the Alpha.jar project (with source code of course). The server part needs to instatiate alpha objects and communicate to the alpha system.
When do this in GWT by adding a build-path-reference to the Alpha project, my GWT app runs fine.
When I instead of the project reference include (in war/WEB-INF/lib) the alpha.jar and runs the app, I get the error in the title the first time I instantiate a class from alpha.jar.
There are no peculiarities in how the alpha.jar is built, so basically it should be the same thing as the project in eclipse, right?
Note the following:
*) The alpha.jar's dependent jars are also in war/WEB-INF/lib. log4j2-core, log4j-api as well as a bunch of others (apache common for example)
*) If I remove the alpha.jar (and the code that calls it) and instead just add code that called LOG4J2, that code also works fine!
How come I get this weird error when using the JAR?? Note also the NoClassDefFoundError, its not the more common ClassNotFoundException. Pls see What causes and what are the differences between NoClassDefFoundError and ClassNotFoundException?
If you need more info let me know.

org.apache.log4j.LogManager is a class from log4j 1.2 (not log4j2).
Therefore, one of your web app jars must be referencing it. The culprit should be visible in the stack trace.
Depending upon your circumstances, you may want to just add a log4j 1.2 jar to the web app as the two versions are completely independent of each other.

If you have use log4j 2 please do not forget to name your log4j2.xml instead of log4j.xml

as refered before:
org.apache.log4j.LogManager is a class from log4j 1.2 (not log4j2).
this problem meets when you combine use log4j 1.2 and log4j 2.x, maybe. so you have to add bridge api to you project.
this is a Migrating problem.
Log4j – Migrating from Log4j 1.x - Apache Log4j 2
add those to you pom.xml
<log4j2.version>2.7</log4j2.version>
<disruptor.version>3.3.6</disruptor.version>
<!--log4j2 dependencies -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>com.lmax</groupId>
<artifactId>disruptor</artifactId>
<version>${disruptor.version}</version>
</dependency>
then, you could use mvn dependency:resolve to see no log4j 1.2
[INFO] The following files have been resolved:
[INFO] org.springframework.data:spring-data-redis:jar:1.7.2.RELEASE:compile
[INFO] org.apache.logging.log4j:log4j-api:jar:2.7:compile
[INFO] org.apache.logging.log4j:log4j-slf4j-impl:jar:2.7:compile
[INFO] com.lmax:disruptor:jar:3.3.6:compile
[INFO] org.apache.logging.log4j:log4j-1.2-api:jar:2.7:compile
[INFO] javax.mail:mail:jar:1.4.5:compile
[INFO] org.springframework:spring-tx:jar:4.3.1.RELEASE:compile
[INFO] org.apache.logging.log4j:log4j-core:jar:2.7:compile
[INFO] org.apache.logging.log4j:log4j-jcl:jar:2.7:compile
[INFO] javax.activation:activation:jar:1.1:compile
[INFO] org.springframework:spring-beans:jar:4.3.1.RELEASE:compile
[INFO] org.springframework:spring-web:jar:4.3.1.RELEASE:compile
[INFO] org.springframework:spring-webmvc:jar:4.3.1.RELEASE:compile
[INFO] org.springframework:spring-oxm:jar:4.2.6.RELEASE:compile
[INFO] org.springframework:spring-jdbc:jar:4.3.1.RELEASE:compile
[INFO] com.alibaba:fastjson:jar:1.2.4:compile
[INFO] mysql:mysql-connector-java:jar:5.1.21:compile
[INFO] org.apache.tomcat:tomcat-servlet-api:jar:7.0.54:provided
[INFO] org.slf4j:slf4j-api:jar:1.7.21:compile
[INFO] org.springframework:spring-context-support:jar:4.3.1.RELEASE:compile
[INFO] commons-beanutils:commons-beanutils:jar:1.8.3:compile
[INFO] org.springframework:spring-context:jar:4.3.1.RELEASE:compile
[INFO] org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] redis.clients:jedis:jar:2.8.1:compile
[INFO] org.springframework:spring-expression:jar:4.3.1.RELEASE:compile
[INFO] org.springframework.data:spring-data-commons:jar:1.12.2.RELEASE:compile
[INFO] org.springframework.data:spring-data-keyvalue:jar:1.1.2.RELEASE:compile
[INFO] junit:junit:jar:4.12:test
[INFO] org.springframework:spring-core:jar:4.3.1.RELEASE:compile
[INFO] commons-logging:commons-logging:jar:1.2:compile
[INFO] org.springframework:spring-aop:jar:4.3.1.RELEASE:compile
[INFO] org.apache.commons:commons-pool2:jar:2.4.2:compile
[INFO] org.slf4j:jcl-over-slf4j:jar:1.7.21:runtime
refers:
Log4j 1.x Adaptor – Log4j 1.2 Bridge - Apache Log4j 1.x Compatibility API
Log4j Commons Logging Adaptor – Commons Logging Bridge - Apache Log4j Commons Logging Bridge
SLF4J Binding Using Log4j – Log4j 2 SLF4J Binding - Apache Log4j SLF4J Binding

IllegalAccessError when calling ant script from maven-antrun-plugin

I just updated Maven from 2.0.9 to 2.2.1 and I'm getting the following exception when running a maven build:
INFO] [antrun:run {execution: precompile-jsp}]
[INFO] Executing tasks
default:
jspc:
[mkdir] Created dir: C:\builds\trunk\webapps\vyre_portlets\WEB-INF\jsp_src
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
C:\unify\trunk\portlets\build-jsps.xml:87: The following error occurred while executing this line:
C:\unify\trunk\portlets\build-jsps.xml:7: java.lang.IllegalAccessError: tried to access method org.apache.tools.ant.launch.Locator.decodeUri(Ljava/lang/String;)Ljava/lang/String; from class org.apache.tools.ant.AntClassLoader
The build-jsps.xml ant script runs the org.apache.jasper.JspC task to precompile JSP in the a webapp that maven is building. This was working fine with Maven 2.0.9.
Google gives a bunch of people asking similar questions, but no answers. Has anyone run into this and knows how to resolve this? Or even just why I'm getting the IllegalAccessError?

try to set ANT dependency for "maven-antrun-plugin" explicitly.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
....
</executions>
<dependencies>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-nodeps</artifactId>
<version>1.7.0</version>
</dependency>
</dependencies>
</plugin>
Note that there are multiple places where you can find ANT in Maven's public repository:
<groupId>org.apache.ant</groupId>
<groupId>ant</groupId>
(2) is the old one so use (1) instead

In Maven 2.2.x, the versions of many of the plugins have been updated, if you run the build with -X, you'll see what version of the antrun-plugin has been used. If these are different versions, it may be using a different version of org.apache.tools.ant.launch.Locator. Looking at the change history for Locator, the decodeUri method was introduced in Ant 1.7 and has been tweaked a few times, though nothing that would obvioulsy cause the problem.
Can you post a minimal pom and ant configuration that shows the error? this would help diagnose the problem.