Hibernate和Apache Felix的依赖链冲突 [英] Dependency chain conflicts for Hibernate and Apache Felix

查看:188
本文介绍了Hibernate和Apache Felix的依赖链冲突的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我理解OSGi抱怨多个依赖链的概念 - 一个包可以多次使用,并且当导入捆绑包没有明确指定它需要的版本时,OSGi容器会遇到不知道是什么的麻烦提供。



不幸的是,我本周遇到了这样一个问题,但这两个捆绑包都是第三方捆绑软件,所以我不能真正影响他们的进口和出口。以下是我得到的两条错误消息:

  org.osgi.framework.BundleException:使用约束违规。无法解析捆绑软件修订版org.hibernate.core [28.0],因为它已经从捆绑软件修订版com.springsource.javax.xml.stream [23.0]和org.apache.felix.framework [ 0]通过两个依赖链。 

链1:
org.hibernate.core [28.0]
导入:(osgi.wiring.package = javax.xml.stream)
|
export:osgi.wiring.package = javax.xml.stream
com.springsource.javax.xml.stream [23.0]

链2:
org。 hibernate.core [28.0]
import:(osgi.wiring.package = javax.xml.transform.stax)
|
export:osgi.wiring.package = javax.xml.transform.stax;使用:= javax.xml.stream
export:osgi.wiring.package = javax.xml.stream
org.apache.felix.framework [0] $ b $ org.apache.felix。 framework.Felix.resolveBundleRevision(Felix.java:3824)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix。 setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:724)



org.osgi.framework.BundleException:使用约束违规。无法解析捆绑软件修订版org.hibernate.core [28.0],因为它从捆绑软件修订版org.apache.felix.framework [0]和com.springsource.javax.xml.stream中公开到软件包javax.xml.stream 23.0]通过两个依赖链。

链1:
org.hibernate.core [28.0]
导入:(osgi.wiring.package = javax.xml.stream)
|
export:osgi.wiring.package = javax.xml.stream
org.apache.felix.framework [0]

链2:
org.hibernate。 core [28.0]
import:(osgi.wiring.package = org.dom4j.io)
|
export:osgi.wiring.package = org.dom4j.io;使用:= javax.xml.stream
com.springsource.org.dom4j [27.0]
import:(&(osgi.wiring.package = javax.xml.stream)(version> = 1.0。 1)(!(版本> = 2.0.0)))
|
export:osgi.wiring.package = javax.xml.stream
com.springsource.javax.xml.stream [23.0]
at org.apache.felix.framework.Felix.resolveBundleRevision( Felix.java:3824)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)$ b $ at java.lang.Thread.run(Thread.java:724)
code>

当我尝试删除 com.springsource.javax.xml.stream 从已安装的软件包中, com.springsource.org.dom4j 抱怨缺少软件包 javax.xml.stream



我检查了 MANIFEST.MF 文件org.apache.felix.framework ,因为我对Felix显然很惊讶,显然导出 javax.xml.stream ,但它不包含这样的条目。另外, dom4j 包不会根据它的清单重新导出流包。



我非常感谢任何提示可以让我更接近地回答这个依赖链问题来自哪里的问题。从我的角度来看,除了 com.springsource.javax.xml.stream 之外,我找不到一个包输出所述包 -

解决方案

如果程序包在bundle中以及bpot类路径(JDK)中可用,则通常会出现问题。如果该软件包是从另一个JDK软件包以及直接从一个软件包进行连接,那么它甚至会是一个更大的问题。在您的情况下,问题如下:


  • javax.xml.transform.stax仅在引导类路径(JDK)上可用,因此hibernate .core连接到该包。

  • 由于javax.xml.transform.stax来自启动类路径,它可以连接到启动类路径上的另一个包。它需要javax.xml.stream,因此它将连接到来自JDK的包



我们有链:

  hibernate.core  - > javax.xml.transform.stax  - > javax.xml.stream 

另一方面,hibernate.core直接连接到javax.xml.stream 。可能它甚至在Import-Package部分使用了一个版本,所以它不能连接到来自JDK的包。



我们有链:

  hibernate.core  - > javax.xml.stream 

这会产生冲突。由于hibernate.core在 javax.xml.transform.stax hibernate.core 的帮助下使用 javax.xml.stream em> javax.xml.transform.stax 应该使用 javax.xml.stream 的相同类。但是,他们没有。



您有几个选项可以解决您的问题:



您可以安装一个包含 javax.xml.transform.stax 包的包。该软件包将能够连接到来自bundle的 javax.xml.stream 包,并且hibernate.core可以连接到包含 javax.xml.transform.stax 的。你可以祈祷,布线总是OK。

根据我的经验,在框架启动后线路良好。由于软件包中的软件包版本较高,因此在从其他软件包导入软件包时它们将是首选。但是,如果在运行时更新和刷新软件包,则连线通常会出错。我不知道为什么,只是发生了。



为了避免出现任何问题,我通常会从引导类路径中排除也可以在捆绑包中使用的那些包。



您的下一个问题可能是这些API经常使用工厂类。当有人使用这样的工厂时,工厂类的类加载器也必须看到实现类。我创建了一个 bundle 包含所有的xmlcommons包。它包含所有的xml-apis类和它们的实现(xerces,xalan等)。这可能对您有所帮助。如果此捆绑包解决了您的问题,请告诉我。在这种情况下,我最终会花时间收集所有必要的数据(授权到POM,资源),并将其发布到maven-central,以便它可以帮助其他人。


I understand the concept of OSGi complaining about multiple dependency chains - a package is available more than once and when the importing bundle doesn't specify exactly which version it needs, so the OSGi container can run into the trouble of not knowing what to provide.

Unfortunately I ran into such a problem this week, but both involved bundles are third party bundles, so I can't really influence their imports and exports. Here are the two error messages I get:

org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.hibernate.core [28.0] because it is exposed to package 'javax.xml.stream' from bundle revisions com.springsource.javax.xml.stream [23.0] and org.apache.felix.framework [0] via two dependency chains.

Chain 1:
  org.hibernate.core [28.0]
    import: (osgi.wiring.package=javax.xml.stream)
     |
    export: osgi.wiring.package=javax.xml.stream
  com.springsource.javax.xml.stream [23.0]

Chain 2:
  org.hibernate.core [28.0]
    import: (osgi.wiring.package=javax.xml.transform.stax)
     |
    export: osgi.wiring.package=javax.xml.transform.stax; uses:=javax.xml.stream
    export: osgi.wiring.package=javax.xml.stream
  org.apache.felix.framework [0]
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3824) 
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
    at java.lang.Thread.run(Thread.java:724)



org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.hibernate.core [28.0] because it is exposed to package 'javax.xml.stream' from bundle revisions org.apache.felix.framework [0] and com.springsource.javax.xml.stream [23.0] via two dependency chains.

Chain 1:
  org.hibernate.core [28.0]
    import: (osgi.wiring.package=javax.xml.stream)
     |
    export: osgi.wiring.package=javax.xml.stream
  org.apache.felix.framework [0]

Chain 2:
  org.hibernate.core [28.0]
    import: (osgi.wiring.package=org.dom4j.io)
     |
    export: osgi.wiring.package=org.dom4j.io; uses:=javax.xml.stream
  com.springsource.org.dom4j [27.0]
    import: (&(osgi.wiring.package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0)))
     |
    export: osgi.wiring.package=javax.xml.stream
  com.springsource.javax.xml.stream [23.0]
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3824)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
    at java.lang.Thread.run(Thread.java:724)

When I try and remove com.springsource.javax.xml.stream from installed bundles, com.springsource.org.dom4j complains about missing package javax.xml.stream.

I checked the MANIFEST.MF file of org.apache.felix.framework because I was really astonished of Felix apparently exporting javax.xml.stream, but it contains no such entry. Also the dom4j bundle does not reexport the streaming package according to it's manifest.

I'd be really grateful for any tips that could get me closer to answer the question where this dependency chain problem comes from. From my point of view I couldn't find a bundle besides com.springsource.javax.xml.stream exporting said package-

解决方案

It is often an issue if a package is available in a bundle and also in the bpot classpath (JDK). It is even a bigger issue if that package is wired from another JDK package and also from a bundle directly. In your case the problem is the following:

  • javax.xml.transform.stax is available only on the boot classpath (JDK) so hibernate.core wires to that package.
  • As javax.xml.transform.stax comes from the boot classpath, it can wire to another package on the boot classpath. It needs javax.xml.stream so it will wire to the package that comes from JDK

We have the chain:

hibernate.core -> javax.xml.transform.stax -> javax.xml.stream

On the other hand, hibernate.core wires to javax.xml.stream directly. Probably it even uses a version in the Import-Package section so it cannot wire to the package that comes from JDK.

We have the chain:

hibernate.core -> javax.xml.stream

This generates a conflict. As hibernate.core uses the javax.xml.stream API with the help of javax.xml.transform.stax, hibernate.core and javax.xml.transform.stax should use the same classes of javax.xml.stream. However, they do not.

You have a couple of options to solve your problem:

You can install a bundle that contains javax.xml.transform.stax package. That package will be able to wire to the javax.xml.stream package that comes from the bundle and also hibernate.core can wire to the bundle that contains javax.xml.transform.stax. You can pray that the wirings will be always OK.

In my experience, the wires are good after the framework is started. As the package versions are higher in the bundles, they will be preferred when the package is imported from other bundles. However, when the bundles are updated and refreshed at runtime, the wiring often goes wrong. I do not know why, it just happens.

To avoid every issue, I normally exclude those packages from the boot classpath that are also available in bundles.

Your next issue might be that these APIs often use factory classes. When someone uses such a factory, the classloader of the factory class must see the implementation classes, too. I created a bundle that contains all of the xmlcommons packages. It contains all of the xml-apis classes and implementation for them (xerces, xalan, etc). It might be helpful for you. If this bundle solves your problem, please let me know. In that case, I will take the time finally to collect all necessary data (licensing into the pom, sources) and release it to maven-central so it can help others as well.

这篇关于Hibernate和Apache Felix的依赖链冲突的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆