2

I have a grizzly http server that runs fine on Windows but fails to start on Ubuntu, throwing the following exception:

Exception in thread "main" 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.server.ApplicationHandler.<init>(ApplicationHandler.java:311)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.<init>(GrizzlyHttpContainer.java:337)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpServerFactory.createHttpServer(GrizzlyHttpServerFactory.java:119)
        at server.ServerCreator.startServer(ServerCreator.java:35)
        at server.ServerCreator.main(ServerCreator.java:41)

On Windows the server starts fine:

Feb 04, 2016 5:57:42 PM org.glassfish.grizzly.http.server.NetworkListener start
INFO: Started listener bound to [localhost:10000]
Feb 04, 2016 5:57:42 PM org.glassfish.grizzly.http.server.HttpServer start
INFO: [HttpServer] Started.

Any suggestions what could be a potential cause for the same code to throw the above exception on Linux specifically? This question suggests that the exception is caused by having both JAX-RS 1 and JAX-RS 2 jars on the classpath, but I have checked for that and if that was the case it should throw the same exception on Windows.

Community
  • 1
  • 1
Andy W
  • 380
  • 1
  • 5
  • 13
  • Might be related to the Jersey versions collision. May be maven transitive dependencies pull in wrong Jersey version. – alexey Feb 04 '16 at 21:34
  • I agree it is likely related to the Jersey versions collision, but why would that only cause the exception to be thrown on Linux and not on Windows? – Andy W Feb 05 '16 at 09:27
  • Hi. I'm experiencing the same issue, did you find a solution? – mxb May 26 '17 at 12:12
  • Yes - basically there were conflicting versions of grizzly in some of the jars in the project (jar hell). One jar had an old version, the other had the latest version. The reason it worked on Windows and not on Linux is because the java classloader behaves differently on different environments (the order of classes being loaded isn't guaranteed), so on Windows it would load the correct dependency but on Linux it loaded the wrong one and the app failed. So I suggest you look for conflicting version of grizzly in your dependencies. I hope this helps, it was a real nightmare figuring this out. – Andy W May 30 '17 at 12:32

0 Answers0