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.

Answer 3

I solve this problem: I delete the library JAX-RS 2.0, I add the libraries jersey-server-1.8.jar,jersey-core-1.8.jar,jersey-servlet-1.12.jar and asm-3.3.1.jar

Answer 4

In my case both jsr311-api-0.10.jar and javax.ws.rs-api-2.0.jar were in the application lib. I deleted jsr311 jar and problem was solved

Answer 5

I had the exact issue could not find the issue. On the first time the Tomcat went up and everything worked but after restarting the server I had the exception.

The solution was to downgrade tomcat to 7.0.26 It did the trick not sure why though.

Answer 6

I didn't realize it, but there was a file named javax.ws-rs-api-2.0.jar already in the WEB-INF/lib folder on the server. It was added two years ago by someone else. It was causing a conflict with the set of jersey files I copied to the WEB-INF/lib folder. I backed up/renamed the file, restarted the service for my container (i.e. Tomcat), and it worked.

Answer 7

We need to make the below changes :

web.xml

    <servlet>
      <servlet-name>RESTful Jersey Web Service Sample</servlet-name>
      <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>      
         <init-param>
                   <param-name>jersey.config.server.provider.packages</param-name>
                   <param-value>com.subu.jersey.rest</param-value>
         </init-param>
    </servlet>

pom.xml

    <dependency>
        <groupId>org.glassfish.jersey.core</groupId>
        <artifactId>jersey-server</artifactId>
        <version>2.17</version>
    </dependency>
    <dependency>
        <groupId>org.glassfish.jersey.containers</groupId>
        <artifactId>jersey-container-servlet-core</artifactId>
        <version>2.17</version>
    </dependency>

Answer 8

In my case both jsr311-api-0.10.jar and javax.ws.rs-api-2.1.jar were in the application lib. I deleted javax.ws.rs-api-2.1.jar and problem was solved

Answer 9

So I faced with same issue when migrating from an eneterprise server to jetty.

Cause: As earlier comments said, there was both Jersey 1 and 2 in the classpath and it was considerable effort to remove either. Issue happens when Jetty loads Jersey jars and whatever is loaded last takes precedence. Here the resource causing issue is javax.ws.rs.ext.RuntimeDelegate (This service bundles and provides other classes including UriBuilder required by Jersey) which is present both in jersey server 1 and 2 (META-INF/services/javax.ws.rs.ext.RuntimeDelegate)

If your servlet container defined in web.xml is that of jersey 2 (org.glassfish.jersey.servlet.ServletContainer) and your appserver loaded RuntimeDelegate from jersey-server 1, we face this issue.

Solution/Hack: If you are in same predicament as I was and want both Jerseys in classpath, You can define this service in war level resource. As it is loaded at the end, it is assured to have whatever specified here will be your final RuntimeDelegate

just create this file in your war package

<war>/WEB-INF/classes/META-INF/services/javax.ws.rs.ext.RuntimeDelegate

with content

org.glassfish.jersey.internal.RuntimeDelegateImpl