AbstractMethodError using UriBuilder on JAX-RS [duplicate]

Question

AbstractMethodError are thrown when an application tries to call an abstract method.

uri is an abstract method in UriBuilder, so you need an implementation of this. This method (with String parameter) is from version 2.0 of JAX-RS specification.

You're trying to use JAX-RS 2.0 with Jersey 1.*. Instead, you need to use Jersey 2.* that implements JAX-RS 2.0 and contains an implementation to uri method.

In your pom.xml you may remove these dependencies:

<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-bundle</artifactId>
    <version>1.19</version>
</dependency>
<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-server</artifactId>
    <version>1.19</version>
</dependency>
<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-core</artifactId>
    <version>1.19</version>
</dependency>
<dependency>
    <groupId>javax.ws.rs</groupId>
    <artifactId>javax.ws.rs-api</artifactId>
    <version>2.0-m12</version>
</dependency>

And use these dependencies:

<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>

Using this, uri method is implemented in JerseyUriBuilder class from jersey-common.

EDIT:

You need to change, in your web.xml, servlet com.sun.jersey.spi.container.servlet.ServletContainer to org.glassfish.jersey.servlet.ServletContainer and init-param from com.sun.jersey.config.property.packages to jersey.config.server.provider.packages

I would like to add one answer to this post. I faced a similar problem today and found the root cause to be another dependent jar which was Internally using an older version of Jersey/JAX-RS.

My POM before fix was:

<jersey.version>2.17</jersey.version>
...
<dependency>
        <groupId>org.glassfish.jersey.core</groupId>
        <artifactId>jersey-server</artifactId>
        <version>${jersey.version}</version>
    </dependency>

    <dependency>
        <groupId>org.glassfish.jersey.containers</groupId>
        <artifactId>jersey-container-servlet-core</artifactId>
        <version>${jersey.version}</version>
    </dependency>

    <dependency>
        <groupId>com.ci.wrapper</groupId>
        <artifactId>client-wrapper</artifactId>
        <version>${clients-wrapper.version}</version>
        <exclusions>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

    <dependency>
        <groupId>com.api.commons</groupId>
        <artifactId>transferobjects</artifactId>
        <version>3.0.2</version>
    </dependency>

The problem was with "com.ci.wrapper" and "com.api.commons". They inturn included 2 different JAR's of BraveJersey and org.apache.cxf.cxf-rt-frontend-jaxrs (2.5.1) which were using Jersey and JAX-RS 1.X versions.

After excluding the nested jar's and adding the newer version's of BraveJersey2/org.apache.cxf.cxf-rt-frontend-jaxrs(3.1.5) it got resolved.

<dependency>
    <groupId>com.api.commons</groupId>
    <artifactId>transferobjects</artifactId>
    <version>3.0.2</version>
    <exclusions>
        <exclusion>
            <artifactId>cxf-rt-frontend-jaxrs</artifactId>
            <groupId>org.apache.cxf</groupId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxrs</artifactId>
    <version>3.1.5</version>
</dependency>

<dependency>
    <groupId>com.ci.wrapper</groupId>
    <artifactId>client-wrapper</artifactId>
    <version>${clients-wrapper.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
        </exclusion>
        <exclusion>
            <artifactId>brave-jersey</artifactId>
            <groupId>com.github.kristofa</groupId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>com.github.kristofa</groupId>
    <artifactId>brave-jersey2</artifactId>
    <version>2.4.2</version>
</dependency>

In case you're facing a similar issue, please check if the project's or jar's included could be using an incompatible version of Jersey/Jax-RS.

In my case it's combination of both cxf-rt-frontend-jaxrs and httpclint jar needed to be removed to resolve the issue. Both of these jars have the class javax.ws.rs.core.UriBuilder, the multiple version of this class caused the issue.

My pom had a transitive dependency on both these jars, after removing it worked.

enter code here
            <exclusion>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-rt-frontend-jaxrs</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpclient</artifactId>
            </exclusion>

I have faced this problem when I was trying to use a library (custom built) in one of my project. So the problem was happening due to mismatch in the com.sun.jersey dependencies. My project was using jersey version 2.15 whereas the custom library was giving me com.sun.jersey transitively of version 1.17.

So how to find such problems.

Use gradle dependencies task to find out the dependencies (it gives nested level results which means all the transitive dependencies will also be shown)

Once you identify the problem causing dependencies. Exclude them while adding the required dependencies in the project.

For e.g. httpRestClient is name of my custom library which I wanted to use in my project. So here is how I have added the dependency and at the same time excluded the conflicting dependencies of group 'com.sun.jersey'

compile(httpRestClient) {
        exclude group: 'com.sun.jersey'
    }

This way you can use whatever library and exclude the conflicting libraries.

Thanks.

In our case culprit was this dependency

<dependency>
    <groupId>org.apache.wink</groupId>
    <artifactId>wink-common</artifactId>
    <version>1.0-incubating</version>
</dependency>