Конфликты цепочек зависимостей для Hibernate и Apache Felix

Question

Я понимаю концепцию OSGi, жаловавшуюся на множественные цепочки зависимостей - пакет доступен несколько раз, и когда импортирующий пакет не указывает точно, какая версия ему нужна, поэтому контейнер OSGi может столкнуться с проблемой не зная, что предоставить.

К сожалению, на этой неделе я столкнулся с такой проблемой, но оба задействованных комплекта являются сторонними комплектами, поэтому я не могу реально повлиять на их импорт и экспорт. Вот два сообщения об ошибках, которые я получаю:

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)

Когда я пытаюсь удалить com.springsource.javax.xml.stream из установленных пакетов, com.springsource.org.dom4j жалуется на отсутствие пакета javax.xml.stream,

Я проверил MANIFEST.MF файл из org.apache.felix.framework потому что я был очень удивлен тем, что Феликс экспортировал javax.xml.stream, но он не содержит такой записи. Так же dom4j bundle не реэкспортирует потоковый пакет в соответствии с его манифестом.

Я был бы очень благодарен за любые советы, которые могли бы приблизить меня к ответу на вопрос, откуда возникает эта проблема цепочки зависимостей. С моей точки зрения я не мог найти связку, кроме com.springsource.javax.xml.stream экспорт указанного пакета

Answer 1

Часто возникает проблема, если пакет доступен в пакете, а также в пути к классам 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 использует API javax.xml.stream с помощью javax.xml.transform.stax, hibernate.core и javax.xml.transform.stax должны использовать те же классы javax.xml.stream. Однако они этого не делают.

У вас есть несколько вариантов решения вашей проблемы:

Вы можете установить пакет, содержащий пакет javax.xml.transform.stax. Этот пакет сможет подключаться к пакету javax.xml.stream, который поставляется из пакета, а также hibernate.core может подключаться к пакету, который содержит javax.xml.transform.stax. Вы можете молиться, чтобы проводка всегда была в порядке.

По моему опыту, провода хороши после запуска фреймворка. Поскольку версии пакетов выше в пакетах, они будут предпочтительнее, когда пакет импортируется из других пакетов. Однако, когда связки обновляются и обновляются во время выполнения, проводка часто выходит из строя. Я не знаю почему, это просто происходит.

Чтобы избежать любой проблемы, я обычно исключаю из пакета загрузочных классов те пакеты, которые также доступны в пакетах.

Ваша следующая проблема может заключаться в том, что эти API часто используют фабричные классы. Когда кто-то использует такую ​​фабрику, загрузчик классов класса фабрики также должен видеть классы реализации. Я создал пакет, содержащий все пакеты xmlcommons. Он содержит все классы xml-apis и их реализацию (xerces, xalan и т. Д.). Это может быть полезно для вас. Если этот пакет решит вашу проблему, пожалуйста, дайте мне знать. В этом случае я, наконец, найду время, чтобы собрать все необходимые данные (лицензирование в pom, источники) и передать их в maven-central, чтобы они также могли помочь другим.