如何在OSGi上使用Jersey解析jersey.internal.RuntimeDelegateImpl

Question

我在OSGi环境中使用Jersey。 我将所有Jetty和Jersey jar包装在一个包含我自己的服务器/ servlet /资源抽象的包中。 这运行得很好。 我通过OSGi包导入导入javax.ws.rs-api，因为相关的包也被其他包中的JAX-RS资源实现使用。

但是，我的实现有时不能使用“java.lang.ClassNotFoundException：javax.ws.rs-api_2.1.0无法找到org.glassfish.jersey.internal.RuntimeDelegateImpl”。

看来这可能是一场竞争。 也许Jersey有时会使用我的内部包中的类，有时也会使用导入的javax中的类。 我无法弄清楚问题是什么。

问题类似于[1]，但在我的情况下，它不是任何导入或依赖。 我将Jetty和Jersey Jars包装在一个OSGi包中。

[1] org.glassfish.jersey.internal.RuntimeDelegateImpl NOT FOUND

Answer 1

出现此问题的原因是JAX-RS API使用许多静态方法来从JAX-RS提供程序获取实现类型。 在这种情况下，错误不是来自Jersey，而是来自JAX-RS API本身，当它试图找到各种JAX-RS接口的实现时。

您实际上有四种选择：

• 通过将所有资源放在那里来避免从服务器公开JAX-RS API （我不推荐这个选项！）
• 将JAX-RS API嵌入现有的Jetty / Jersey uber软件包并从那里导出。 小心包含正确的API包版本和合同功能！ （这个选项很繁琐）
• 使用支持OSGi的API包（例如来自Apache Aries，Apache Geronimo或Apache Service Mix的API）。 许多Java EE API包（包括JAX-RS）将自己打包为OSGi包，但忽略了它们实际上需要在OSGi中工作的事实，这意味着您不能依赖于反向从平面类路径加载类型/资源。 （这个选项可能是最快的，让你继续工作）
• 转而使用OSGi Release 7中新的OSGi JAX-RS白板。这个参考实现在Apache Aries中， 可以在GitHub上获得 （从OSGi的角度来看，这是最好的长期选项，这意味着你可以避免维护自己的服务器）

我希望这一切都有意义，解释为什么你会看到错误，并希望为你提供一些解决问题的方法。