以下问题讨论了泽西岛和 JAX-RS 规范之间的依赖关系理论:

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>

到我的 API 定义 maven 项目并使用 Jersey/Grizzly 进行实施.

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)

应该与 Jersey 1.15 一起使用的正确 JAX-RS API 依赖项是什么?

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

我想以一种可以将实现替换为任何其他符合 JAX-RS 的库的方式来实现.

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

推荐答案

问题是您的 JSR 311 API 依赖是 1.0 版，而 Jersey 1.15 是 JSR 311 1.1 版实现.比较 http://jsr311.java.net/nonav/releases/1.0/javax/ws/rs/core/Response.Status.html 和 http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/Response.Status.html，你会看到后者实现了ResponseType 接口，但前者没有.

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.

通过声明如下内容，您应该能够在构建时类路径中拥有 JSR 311 版本 1.1.1 API 类文件:

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>

事实上，jersey-core pom.xml 已经这样做了——上面只是 http://repo1.maven.org/maven2/com/sun/jersey/jersey-core/1.15/jersey-core-1.15.pom.

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.

在像 Glassfish 这样的容器中，您现在已经完成了，因为容器将负责在运行时为您提供 API 类(这就是为什么 jersey 自己的 Maven POM 中的范围是 provided，而不是编译).但是，对于 Grizzly Web 容器，您可能需要确保 API 类在运行时可用(通过使用上面的 <dependency> 声明，但更改 <从 provided 到 compile 的范围> 将执行此操作.

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).