2015-12-01 7 views
5

Ich versuche JackRabbit 2.11.1 zu verwenden, um eine Verbindung zu einem Remote-Repo herzustellen (mit Hilfe von jackrabbit-jcr-rmi). Die Bundles laufen in JBoss Fuse 6.2, die Apache Karaf 2.4/Felix 4.4 unter der Haube hat. Beim Start bekomme ich die Ausnahme unten. Wenn ich versuche, Jackrabbit-Bundle zu verwenden, bekomme ich "Fehlende Einschränkung: Import-Paket: com.ibm.db2.jcc; version =" 0.0.0 "" Also ich bin verwirrt, ist JackRabbit 2.x OSGi bereit ? oder brauche ich Sling oder Eiche oder ....?OSGi-Fehler bei der Ausführung von jackrabbit 2.11 in Karaf 2.4/Felix 4.x

Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision wrap_mvn_org.apache.jackrabbit_jackrabbit-core_2.11.1 [270.0] because it exports package 'org.apache.jackrabbit.core.config' and is also exposed to it from bundle revision org.apache.jackrabbit.jackrabbit-data [276.0] via the following dependency chain: 
wrap_mvn_org.apache.jackrabbit_jackrabbit-core_2.11.1 [270.0] 
import: (osgi.wiring.package=org.apache.jackrabbit.core.data.db) 
export: osgi.wiring.package=org.apache.jackrabbit.core.data.db; uses:=org.apache.jackrabbit.core.config 
export: osgi.wiring.package=org.apache.jackrabbit.core.config 
org.apache.jackrabbit.jackrabbit-data [276.0] 
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4006)[org.apache.felix.framework-4.4.1.jar:] 
at org.apache.felix.framework.Felix.startBundle(Felix.java:2045)[org.apache.felix.framework-4.4.1.jar:] 
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:976)[org.apache.felix.framework-4.4.1.jar:] 
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:963)[org.apache.felix.framework-4.4.1.jar:] 
at org.apache.karaf.features.internal.FeaturesServiceImpl.doInstallFeatures(FeaturesServiceImpl.java:546)[9:org.apache.karaf.features.core:2.4.0.redhat-620133] 

Siehe auch https://issues.apache.org/jira/browse/JCR-3917

+0

i indem Sie die Anweisungen auf http einen Schritt näher gekommen /aries.apache.org/modules/spi-fly.html aber der "konsumierende" Teil (mein Jar) sieht den Provider immer noch nicht. Siehe den Kommentar auf https://issues.apache.org/jira/browse/JCR-3917?focusedCommentId=15037547&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15037547 – rwijngaa

+0

Das einzige, was ich kann vorschlagen, dass Sie hier eine Kombination von Bündeln haben, die nicht zusammen funktionieren. Insbesondere würde ich 'wrap_mvn_org.apache.jackrabbit_jackrabbit-core_2.11.1' verdächtigen. Das hört sich so an, als wäre es mit einem automatischen Prozess verpackt worden und hat daher wahrscheinlich schlechte Metadaten. –

Antwort

1

ich es mit einem schrecklichen Hack gelöst.

  • Betten Sie die Abhängigkeiten, die ich brauche, in mein eigenes Glas ein.
  • Setzen Sie den ContextClassLoader auf den Klassenlader der bereitstellenden Klasse (was die SPI-Sache in erster Linie tun sollte, aber nicht funktionierte, wahrscheinlich weil ich mehr Gläser als die, die ich tat, wickeln musste).

Also, in der Maven-Bundle-Plugin i tat

<Embed-Dependency>jackrabbit-jcr2dav*,jackrabbit-jcr2spi*,jackrabbit-jcr-commons*;scope=compile;inline=false</Embed-Dependency> 

Und in meinem raubend Code: /:

ClassLoader originalContextClassLoader = Thread.currentThread().getContextClassLoader(); 
Thread.currentThread().setContextClassLoader(Jcr2davRepositoryFactory.class.getClassLoader()); 
// 
repository = JcrUtils.getRepository(uri); 
session = getSession(); 
// restore original classloader 
Thread.currentThread().setContextClassLoader(originalContextClassLoader); 
Verwandte Themen