NoSuchMethodError on Values.lazy (Jersey 2.5.1)

Question

I am officially perplexed by this blocker.

I had upgraded Jersey from 2.4.1 to 2.5.1 because Jersey/Oracle fixed a package scanning bug that was affecting getting Swagger working. 2.4.1 was working relatively "okay" after lots of hacks to integrate with our Spring-based server (spring-jersey3 was not working at all.) Now since upgrading to 2.5.1 (and now, 2.6-SNAPSHOT), I receive the error below each time I make a request to anything matching the API URL pattern.

What I have done:

• Redeployed on a new, clean server (clean maven repository, clean tomcat, etc);
• Checked that the jar is the correct version (and even decompiled the "Value" class to ensure it was the one I see on GitHub that was updated ~2 months ago);
• Looked at all of the jars using tattletale to look for class conflicts;
• Upgraded to 2.6-SNAPSHOT (noted above), building the latest;
• Posted a bug (no response);

Help/work-arounds/debugging ideas much appreciated... don't even know what more I can do besides scrapping Swagger, a few days of work, and rolling back to 2.4.1

Feb 12, 2014 15:46:24 ERROR [TP-Processor6] [Catalina].[localhost].[/company
[Jersey REST Service] - Servlet.service() for servlet Jersey REST Service threw           
exception java.lang.NoSuchMethodError:
org.glassfish.jersey.internal.util.collection.Values.lazy(Lorg/glassfish/jersey/internal/util
collection/Value;)Lorg/glassfish/jersey/internal/util/collection/Value;
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.company.videoapp.server.springframework.SessionFilter.doFilter(SessionFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.company.videoapp.server.springframework.loader.ContextLoaderHttpInterceptor$LoaderState.filter(ContextLoaderHttpInterceptor.java:75)
at com.company.videoapp.server.springframework.loader.ContextLoaderHttpInterceptor$StartedState.filter(ContextLoaderHttpInterceptor.java:120)
at com.company.videoapp.server.springframework.loader.ContextLoaderHttpInterceptor.doFilter(ContextLoaderHttpInterceptor.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:662)

---

Update

I got rid of the ubiquitous 500 error, but I still get that exception. Here are some observations --

2.5.1 & 2.6-SNAPSHOT

Interfaces... inheritance... very buggy in 2.5.1+ (at least two regression bugs.)

My constant 500 errors were due to this, so after removing the interfaces I can at least hit a valid endpoint. Scenarios below:

Broken scenario #1 -- Implementing Resource Interface

@Path(MY_PATH)
@Produces(...)
@Consumes(...)
interface MyResource {
   ...
   @GET myResourceMethod();
}

.

public class MyAwesomeResource implements MyResource {
   ...
}

Sending a request to the above resource results in a 404 exception, which in turn results in a 500 for the client because of some unknown issue possibly related to the exception above.

Broken scenario #2 -- Making interface public

@Path(MY_PATH)
@Produces(...)
@Consumes(...)
public interface MyResource {
   ...
   @GET myResourceMethod();
}

.

public class MyAwesomeResource implements MyResource {
   ...
}

Results in another 500 from an internal NoSuchMethodError exception (the one in the comment -- "Could not find a suitable constructor in MyResource.class") when issuing a request to the resource

The exception posted in the original question is masking real exceptions (404 becomes 500... I have to remote debug to see the actual exception.)

Hope Jersey devs are paying attention to this. Not cool.

Answer 1

Based on informations provided in JERSEY-2394 your class-path contains these libraries:

rw-rr- 1 root root 94774 Feb 10 12:02 cxf-rt-databinding-jaxb-2.3.2.jar
rw-rr- 1 root root 341446 Feb 10 12:02 cxf-rt-frontend-jaxws-2.3.2.jar
rw-rr- 1 root root 20020 Feb 10 12:02 jackson-jaxrs-base-2.2.3.jar
rw-rr- 1 root root 15243 Feb 10 12:02 jackson-jaxrs-json-provider-2.2.3.jar
rw-rr- 1 root root 25985 Feb 10 12:02 jackson-module-jaxb-annotations-2.2.3.jar
rw-rr- 1 root root 50034 Feb 10 12:02 jackson-module-jsonSchema-2.1.0.jar
rw-rr- 1 root root 79309 Feb 10 12:02 javax.json-1.0.2.jar
rw-rr- 1 root root 19754 Feb 10 12:02 javax.json-api-1.0.jar
rw-rr- 1 root root 876610 Feb 10 12:02 jaxb-impl-2.1.13.jar
rw-rr- 1 root root 226915 Feb 10 12:02 jaxen-1.1.1.jar
rw-rr- 1 root root 159742 Feb 10 14:02 jersey-client-2.5.1.jar
rw-rr- 1 root root 700399 Feb 10 14:02 jersey-common-2.5.1.jar
rw-rr- 1 root root 15684 Feb 10 14:02 jersey-container-servlet-2.5.1.jar
rw-rr- 1 root root 52593 Feb 10 12:02 jersey-container-servlet-core-2.1.jar
rw-rr- 1 root root 6412 Feb 10 14:02 jersey-media-json-processing-2.5.1.jar
rw-rr- 1 root root 63067 Feb 10 12:02 jersey-media-multipart-2.1.jar
rw-rr- 1 root root 828016 Feb 10 14:02 jersey-server-2.5.1.jar
rw-rr- 1 root root 86540 Feb 10 12:02 json4s-ast_2.10-3.2.4.jar
rw-rr- 1 root root 568890 Feb 10 12:02 json4s-core_2.10-3.2.4.jar
rw-rr- 1 root root 74565 Feb 10 12:02 json4s-ext_2.10-3.2.4.jar
rw-rr- 1 root root 39952 Feb 10 12:02 json4s-jackson_2.10-3.2.4.jar
rw-rr- 1 root root 68734 Feb 10 12:02 json4s-native_2.10-3.2.4.jar
rw-rr- 1 root root 7814 Feb 10 12:02 jsonp-jaxrs-1.0.jar
rw-rr- 1 root root 121047 Feb 10 12:02 swagger-jaxrs_2.10-1.3.2.jar
rw-rr- 1 root root 45719 Feb 10 12:02 swagger-jersey2-jaxrs_2.10-1.3.2.jar

You have 2 Jersey jars with different version than 2.5.1 - jersey-media-multipart-2.1.jar and jersey-container-servlet-core-2.1.jar. The latter one causes the problem you have. Lines from the stacktrace correspond with the idea that 2.1 version of jersey servlet core is used instead of 2.5.1 (see WebComponent from 2.1). The solution would be to remove the old jars.