4

The following questions discusses the theory of the dependencies between Jersey and the JAX-RS specification:

I was assuming that I could add the dependency:

  <!--  javax.ws.rs.core e.g. Request -->
  <dependency>
     <groupId>javax.ws.rs</groupId>
     <artifactId>jsr311-api</artifactId>
     <version>1.0</version>
  </dependency>

to my API defining maven project and use Jersey/Grizzly for the implementation.

    <jersey.version>1.15</jersey.version>
    <grizzly.version>2.2.20</grizzly.version>       

Contrary to this assumption I got the following error message:

15.02.2013 08:41:25 org.glassfish.grizzly.http.server.HttpServerFilter handleRead
WARNUNG: Unexpected error
java.lang.IncompatibleClassChangeError: Class javax.ws.rs.core.Response$Status does not implement the requested interface javax.ws.rs.core.Response$StatusType
    at com.sun.jersey.spi.container.ContainerResponse.getStatus(ContainerResponse.java:571)

What is the correct JAX-RS API dependency that should be used with Jersey 1.15?

I'd like to do it in a way that the implementation could be replaced by any other JAX-RS compliant library.

Community
  • 1
  • 1
Wolfgang Fahl
  • 15,016
  • 11
  • 93
  • 186

2 Answers2

5

The problem is your JSR 311 API dependency is version 1.0, whereas Jersey 1.15 is a JSR 311 version 1.1 implementation. Compare http://jsr311.java.net/nonav/releases/1.0/javax/ws/rs/core/Response.Status.html and http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/Response.Status.html, and you will see that the latter implements the ResponseType interface, but the former does not.

You should be able to have the JSR 311 version 1.1.1 API class files on the build-time classpath by declaring something like this:

<dependency>
    <groupId>javax.ws.rs</groupId>
    <artifactId>jsr311-api</artifactId>
    <version>1.1.1</version>
    <scope>provided</scope>
</dependency>

In fact, the jersey-core pom.xml already does this - the above is just the first dependency in http://repo1.maven.org/maven2/com/sun/jersey/jersey-core/1.15/jersey-core-1.15.pom.

In a container like Glassfish, you'd now be done, since the container would be responsible for providing the API classes for you at runtime (which is why the scope in jersey's own Maven POM is provided, not compile). However, for the Grizzly web container, it is likely you'll need to ensure that the API classes are available at runtime (by using the <dependency> declaration above, but changing <scope> from provided to compile will do this).

David Conneely
  • 896
  • 6
  • 9
  • do I need to have dependency for `api` as well? I just have ` org.glassfish.jersey.core jersey-server 2.7 org.glassfish.jersey.ext jersey-spring3 2.8 ` – daydreamer May 03 '14 at 15:15
-1

Well, if you simply use jersey, you annotate your code with standard annotation like

import javax.ws.rs.Path;

The class is actually provided by jersey jars. However, as this is the standard name for the annotation, removing the jersey dependency and using another implementation of JSR-311, you MIGHT be able to make it work without too much pain. But this looks better in theory than in practice in my opinion. These kind of things rarely go as smoothly as expected.

So I'm afraid there is no satisfying answer to your question (but I would be glad to be wrong)...

ben75
  • 29,217
  • 10
  • 88
  • 134
Samuel EUSTACHI
  • 3,116
  • 19
  • 24