4

以下问题讨论了 Jersey 和 JAX-RS 规范之间的依赖关系理论：

我假设我可以添加依赖项：

  <!--  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 进行实施。

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

与此假设相反，我收到以下错误消息：

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 依赖项是什么？

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

4

2 回答 2

5

问题是您的 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接口，但前者没有。

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

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

事实上，jersey-corepom.xml已经这样做了——上面只是http://repo1.maven.org/maven2/com/sun/jersey/jersey-core/1.15/jersey-core-1.15.pom中的第一个依赖项.

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

于 2013-02-17T00:23:10.160 回答
-1

好吧，如果您只是使用球衣，您可以使用标准注释来注释您的代码，例如

import javax.ws.rs.Path;

该类实际上是由 jersey jars 提供的。但是，由于这是注释的标准名称，删除球衣依赖并使用 JSR-311 的另一种实现，您可能能够使其工作而没有太多痛苦。但在我看来，这在理论上比在实践中看起来更好。这类事情很少能像预期的那样顺利。

所以我担心你的问题没有令人满意的答案（但我很高兴错了）......

于 2013-02-15T08:57:01.283 回答