I have a maven project which produces a .war application. When I deploy this war in my local installation of jetty9 the app works. When I deploy to my machine in AWS it fails to start with the following error.
2017-07-05 17:53:43.336:WARN:oejuc.AbstractLifeCycle:main: FAILED o.e.j.w.WebAppContext@3dd3bcd{/my-app,file:/var/cache/jetty9/data/jetty-0.0.0.0-8080-my-app.war-_my-app-any-5436545420435013189.dir/webapp/,STARTING}{/my-app.war}: java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:331)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:392)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:369)
This is a Jersey 2 app which communicates with another api via an old client written in Jersey 1. I've already had conflicts between both versions of Jersey and solved them using maven exclusions as indicated here, and that solved the problem locally, but for some reason it now fails when I deploy.
I've failed to spot the difference between the two environments. I ran java -jar /usr/share/jetty9/start.java --version and the result is identical (I diffed it) in both machines:
Jetty Server Classpath:
-----------------------
Version Information on 38 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: (none specified) | ${jetty.home}/eclipse-ecj-3.11.0.jar
1: 9.2.18.v20160721 | ${jetty.home}/jetty9-apache-jsp.jar
2: 1.2.5 | ${jetty.home}/taglibs-standard-impl.jar
3: 1.2.5 | ${jetty.home}/taglibs-standard-spec.jar
4: 8.0.37 | ${jetty.home}/tomcat8-api-8.0.37.jar
5: 3.0.FR | ${jetty.home}/tomcat8-el-api-8.0.37.jar
6: 8.0.37 | ${jetty.home}/tomcat8-jasper-8.0.37.jar
7: 8.0.37 | ${jetty.home}/tomcat8-jasper-el-8.0.37.jar
8: 2.3.FR | ${jetty.home}/tomcat8-jsp-api-8.0.37.jar
9: 8.0.37 | ${jetty.home}/tomcat8-juli-8.0.37.jar
10: 8.0.37 | ${jetty.home}/tomcat8-util-8.0.37.jar
11: 8.0.37 | ${jetty.home}/tomcat8-util-scan-8.0.37.jar
12: (dir) | ${jetty.base}/resources
13: 3.1.FR | ${jetty.home}/servlet-api-3.1.jar
14: 9.2.18.v20160721 | ${jetty.home}/jetty9-http.jar
15: 9.2.18.v20160721 | ${jetty.home}/jetty9-server.jar
16: 9.2.18.v20160721 | ${jetty.home}/jetty9-xml.jar
17: 9.2.18.v20160721 | ${jetty.home}/jetty9-util.jar
18: 9.2.18.v20160721 | ${jetty.home}/jetty9-io.jar
19: 9.2.18.v20160721 | ${jetty.home}/jetty9-jndi.jar
20: 1.5.6 | ${jetty.home}/javax.mail.jar
21: 9.2.18.v20160721 | ${jetty.home}/jetty9-security.jar
22: 9.2.18.v20160721 | ${jetty.home}/jetty9-servlet.jar
23: 9.2.18.v20160721 | ${jetty.home}/jetty9-webapp.jar
24: 9.2.18.v20160721 | ${jetty.home}/jetty9-deploy.jar
25: 9.2.18.v20160721 | ${jetty.home}/jetty9-plus.jar
26: 9.2.18.v20160721 | ${jetty.home}/jetty9-annotations.jar
27: 3.0.FR | ${jetty.home}/tomcat8-annotations-api-8.0.37.jar
28: 5.1 | ${jetty.home}/asm-commons-5.1.jar
29: 5.1 | ${jetty.home}/asm-5.1.jar
30: 1.1.FR | ${jetty.home}/tomcat8-websocket-api-8.0.37.jar
31: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-client-impl.jar
32: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-server-impl.jar
33: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-api.jar
34: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-client.jar
35: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-common.jar
36: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-server.jar
37: 9.2.18.v20160721 | ${jetty.home}/jetty9-websocket-servlet.jar
My question is: what could be different in the AWS machine that could cause this error? Where else should I look to get more info to solve this problem?
Apparently the exclusions were not correctly configured. I was excluding com.sun.jersey:jersey-server but javax.ws.rs:jsr311-api was being included as a transitive dependency of com.sun.jersey:jersey-client. I explicitly excluded javax.ws.rs:jsr311-api and it worked.
I still don't know why it was working in my local jetty installation. A teammate suggested it may have something to do with the order the jars where loaded on each machine, but I'm not sure how to check that.