我一直在阅读各种使用 Jersey HTTP 客户端包的 Java 库,我应该小心,因为它们使用 Jersey 2.x,如果我的类路径中已经有 Jersey 1.x,它可能会导致一些冲突。
但是,从版本 2.x 开始,Jersey 项目在合并到 Glassfish 项目时更改了组 ID 和包名称。
既然包名不同,会有什么冲突?如果我的可部署文件中有 Jersey 1.x,将使用这些类,因为 Glassfish Runtime 提供的 Jersey 2.x 是完全不同的类,具有不同的名称。
同样,如果我的可部署文件中有 Jersey 1.x,并且一些依赖项出现并添加了 Jersey 2.x,我可能遇到的唯一问题如下:没有部署描述符,Glassfish 将使用它的版本库,而不是提供的库。但无论如何,应该不会出现问题,因为我的类路径中同时包含 Jersey 1.x 和 2.x,对吧?
请指教,我错过了什么吗?有什么大惊小怪的?
最佳答案
是的,你应该!
当您的项目附加了您无法控制的依赖项时,请务必慎重考虑。
一个是你提到的,从 1.x 到 2.x,他们已经从 sun
命名空间移动到 glassfish
命名空间。
在 1.x 中,他们使用 JAX-RS 的 JEE6 版本,在 2.x 中,他们使用 JAX-RS 的 JEE7 版本。这是一个大问题。比如javax.ws.rs.core.Application
在不同版本的jersey中使用是不一样的,不能一模一样。
Jesey 2.x 使用 JEE 7。在 JEE 7 版本的 javax.ws.rs.core.Application
中有
getClasses()
getSingletons()
getProperties()
定义的方法。 https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Application.html
Jesey 1.x 使用 JEE 6。在 JEE 6 版本的 javax.ws.rs.core.Application
中只有
getClasses()
getClass()
但是 getProperties()
没有定义。 https://jersey.github.io/apidocs/1.19.1/jersey/javax/ws/rs/core/Application.html
这可能会导致像 NoSuchMethodError
https://docs.oracle.com/javase/7/docs/api/java/lang/NoSuchMethodError.html 这样的错误
这只是一个无能。我敢肯定,如果您深入挖掘,您会发现更多。
不仅是命名空间,底层实现也改了一个日志。是的,glassfish 运行时加载了 Jersey 。但是您可能会遇到麻烦,因为尽管指定了provided 范围,但不同的工件名称可能会导致不一致。
关于java - 为什么 Jersey 1.x 会与 Jersey 2.x 冲突?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47347072/