java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri

Question

I try to start application but using Tomcat 7 and I've got an exception like this.

I think this can be something with Maven dependency, but I'm sure. If some know what is going on please for answer:)

Exception:

message Servlet execution threw an exception  description The server encountered an internal error that prevented it from fulfilling this request.  exception  javax.servlet.ServletException: Servlet execution threw an exception     org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)  root cause  java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder;     javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119)     com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:651)     javax.servlet.http.HttpServlet.service(HttpServlet.java:728)     org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) note The full stack trace of the root cause is available in the Apache Tomcat/7.0.50 logs. 

Maven POM:

<properties>         <application.version>1.0</application.version>         <spring.version>4.0.0.RELEASE</spring.version>         <spring.security.version>3.2.0.RELEASE</spring.security.version>         <jersey.version>1.18.1</jersey.version>     </properties>        <dependencies>         <dependency>             <groupId>climbing-portal-facade</groupId>             <artifactId>climbing-portal-facade</artifactId>             <version>${application.version}</version>         </dependency>         <dependency>             <groupId>com.sun.jersey</groupId>             <artifactId>jersey-core</artifactId>             <version>${jersey.version}</version>         </dependency>         <dependency>             <groupId>com.sun.jersey</groupId>             <artifactId>jersey-server</artifactId>             <version>${jersey.version}</version>         </dependency>         <dependency>             <groupId>com.sun.jersey</groupId>             <artifactId>jersey-json</artifactId>             <version>${jersey.version}</version>         </dependency>         <dependency>             <groupId>org.glassfish.jersey.test-framework.providers</groupId>             <artifactId>jersey-test-framework-provider-jdk-http</artifactId>             <version>2.7</version>         </dependency>          <!-- Jersey + Spring -->         <dependency>             <groupId>com.sun.jersey.contribs</groupId>             <artifactId>jersey-spring</artifactId>             <version>${jersey.version}</version>             <exclusions>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring</artifactId>                 </exclusion>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring-core</artifactId>                 </exclusion>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring-web</artifactId>                 </exclusion>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring-beans</artifactId>                 </exclusion>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring-context</artifactId>                 </exclusion>                 <exclusion>                     <groupId>org.springframework</groupId>                     <artifactId>spring-aop</artifactId>                 </exclusion>             </exclusions>         </dependency>         <dependency>             <groupId>org.springframework</groupId>             <artifactId>spring-web</artifactId>             <version>${spring.version}</version>         </dependency>     </dependencies> 

Any idea ?

Answer 1

You're using both Jersey 1 & 2 (Jersey 1 is an explicit dependency, Jersey 2 is a transitive dependency of jersey-test-framework-provider-jdk-http) and that's not possible - so the classloader is picking up the wrong URIBuilder class.

The Jersey dependencies in group com.sun.jersey are all Jersey version 1. Jersey version 2 uses the group org.glassfish.jersey.

You have both in your Maven dependencies which is causing this problem.

If possible only use Jersey 2.

Answer 2

This can also be caused by including both

<dependency>   <groupId>com.sun.jersey</groupId>   <artifactId>jersey-server</artifactId>   <version>1.xxx</version> </dependency> 

And

<dependency>   <groupId>javax.ws.rs</groupId>   <artifactId>javax.ws.rs-api</artifactId>   <version>2.xx</version> </dependency> 

com.sun.jersey artifacts include a version (1.0) of the javax.ws.rs namespace so it's the only one that's likely needed. rs-api also includes a version of JAX-RS (2.0) in the same namespace, so when you have the two together, but they're different versions it can cause the conflict you see.

This can be caused by having "any" conflict that provides both JAX-RS 1.0 and JAX-RS 2.0. JAX-RS 1.0 is frequently provided by the com.sun.jersey:jersey* artifacts (specifically jersey-core), and JAX-RS 2.0 is provided by any of the org.glassfish.jersey.core:jersey* artifacts, or the javax.ws.rs:javax.ws.rs-api artifact, or possibly the javax:javaee-api artifact, or the jsr311-api-1.0 artifact.

The problem is that since they are different group+artifact names, maven by default will unknowingly include both 1.0 and 2.0 version jars into your final distro.

Further complicating the problem is that since there are multiple conflicting jars in the classpath, "sometimes" it might work, and then "sometimes" it might not (hence some reports of "it worked with tomcat7, but fails with tomcat8" etc.)

Further complicating the problem is that if you have even a single dependency that transitively depends on any of the above, then maven will bring in both versions and you're hosed. You can find what's coming from where with mvn dependency:tree

So you have to either go to "all 1.0" or "all 2.0." In our case we went with all 1.0 by adding some transitive dependency exclusions to our pom. If you want to go all 2.0 see here.