28

I've been getting a very strange error when trying to start a Jersey app on Tomcat. The same code works on other computers. I tried reinstalling tomcat, all my maven dependencies, even Eclipse and Java itself, no luck. It seems like a bad Jersey version is being loaded, I think?

Any pointers in the right direction will be appreciated.

Here's the effective pom: http://pastebin.com/NacsWTjz

And the actual pom: http://pastebin.com/H6sHe4ce

2015-02-13 13:43:40,870 [localhost-startStop-1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/middleware-server] - StandardWrapper.Throwable
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
    at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:304)
    at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
    at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311)
    at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
    at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
    at javax.servlet.GenericServlet.init(GenericServlet.java:158)
    at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4901)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5188)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
SGr
  • 853
  • 2
  • 9
  • 15
  • 2
    Looks like you have incompatible jars in your classpath – Jens Feb 13 '15 at 21:53
  • 3
    I hope you are not in a jar hell. – Tanmay Patil Feb 13 '15 at 22:03
  • I've been in jar hell for the last 3 days.. didn't get any work done because of that. – SGr Feb 13 '15 at 22:03
  • You have a version mismatch. Can you post your pom? – John R Feb 13 '15 at 22:09
  • Here's the effective pom, thank you so much: http://pastebin.com/NacsWTjz – SGr Feb 13 '15 at 22:22
  • One thing I don't see in the effective pom is the `javax.ws.rs.-api-2.0.1.jar`. Can you post the actual pom (here), and not the effective pom (somewhere else) – Paul Samsotha Feb 14 '15 at 05:33
  • Just an FYI, this error is often a conflict of us using the jax-rs 1 api, when we really need the jax-rs 2 api – Paul Samsotha Feb 14 '15 at 05:36
  • The actual pom: http://pastebin.com/H6sHe4ce – SGr Feb 14 '15 at 07:11
  • That doesn't help. We don't have the parent – Paul Samsotha Feb 14 '15 at 07:18
  • It's parent: http://pastebin.com/P3wsKy5V and that parent's parent has the jersey stuff: http://pastebin.com/hKicrwDg – SGr Feb 14 '15 at 07:21
  • Run `mvn dependency:tree -Dverbose` to see If any of the dependencies depend on `jsr-311`. In which case, you will need to exclude it – Paul Samsotha Feb 14 '15 at 07:22
  • Also look in your tomcat libs. Maybe it is in there. I'll test your pom when I get a chance – Paul Samsotha Feb 14 '15 at 07:30
  • There's 4 occurences of modules that rely on `com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.0.0:compile` which depends on jsr-311. There are 28 occurences of modules that depend on jsr-305. – SGr Feb 14 '15 at 07:30
  • Try and exclude it (jsr-311). jsr-311 is JAX-RS 1. This is a conflict as Jersey 2 uses JAX-RS 2, but there are still some classes like `Application` that are the same. JAX-RS 1 will not have the method `getProperties`, as shown in the exception. – Paul Samsotha Feb 14 '15 at 07:31
  • Do this, just add `jackson-jaxrs-json-provider:2.3.2`. And don't worry about anything else. See if the app runs. This will cause the 2.0 not to be included. Not sure if it will break anything else though – Paul Samsotha Feb 14 '15 at 07:35
  • You may be able to just exclude the jsr jar. Add ` javax.ws.rs jsr311-api ` to the swagger dependency – Paul Samsotha Feb 14 '15 at 07:57
  • So I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider is overriden by a 2.4.1 provider. So we don't need to add it ourselves. When it's overriden, it seems to leave behind the jsr-311 jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem – Paul Samsotha Feb 14 '15 at 08:04
  • That worked! Thank you so much, please post it as an answer so I can give you the reputation you more than deseve. – SGr Feb 14 '15 at 08:27

3 Answers3

67

Note: Please see above comments for further discussion and tips.

This error usual means that you have a both a JAX-RS 1 and JAX-RS 2 jar on the classpath. Jersey 2 uses JAX-RS 2 (javax.ws.rs-api-2.0.1.jar), but if you have the jsr311-api.jar also, which is JAX-RS 1, there is a javax.ws.rs.core.Application in each jar. But the jsr311-api Application doesn't have the method getProperties() (hence NoSuchMethodError).

I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider (which depends on JAX-RS 1) seems to be overridden by a 2.4.1 provider (which uses the new version). So we don't need to add it ourselves. When it's overridden, it seems to leave behind the jsr311-api.jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem

<dependency>
    <groupId>com.wordnik</groupId>
    <artifactId>swagger-core_2.10</artifactId>
    <version>1.3.11</version>
    <exclusions>
        <exclusion>
            <groupId>javax.ws.rs</groupId>
            <artifactId>jsr311-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>
Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
  • 1
    In my case the `jsr311-api.jar` came with `spring-cloud-starter-eureka`, so excluding it there (like @peeskillet showed) solved my problem. – Sonata Jul 27 '17 at 12:50
  • The version I am using is a little different: jaxrs-ri-2.28.zip. I am able to create a war file with maven. – DoesEatOats Nov 02 '19 at 20:03
0

We are using jersey-json 1.9 which has a dependency on jersey-core which also happen to have a javax.ws.rs.core.Application class.

So our fix is to exclude the jersey-core from jersey-json:

    <dependency>
        <groupId>com.sun.jersey</groupId>
        <artifactId>jersey-json</artifactId>
        <version>1.9</version>
        <exclusions>
            <exclusion>
                <groupId>com.sun.jersey</groupId>
                <artifactId>jersey-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
LeOn - Han Li
  • 9,388
  • 1
  • 65
  • 59
0

the problem is related about "com.sun.jersey:jersey-core:jar:1.18.3" (or any 1.* version) because old versions of Jersey didn't have that "public Map getProperties()" method.

And one of your dependencies use Jersey version 1 (you can check that in running mvn dependency:tree and search all jersey-core version used)

Me I have resolved the problem deleting all com.sun.jersey dependancies (old api) and using the new one org.glassfish.jersey API

https://mvnrepository.com/artifact/org.glassfish.jersey.core

Walterwhites
  • 1,287
  • 13
  • 9