In what scenario, the following error could happen? This happens sporadically when starting an application with several bundles. What would be the fix for this error?
Caused by: org.osgi.framework.BundleException: Unable to resolve module com.springsource.slf4j.api [135.0] because it exports package 'org.slf4j.spi' and is also exposed to it from com.springsource.slf4j.api [135.0] via the following dependency chain:
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j.impl)(version>=1.6.1)(!(version>=2.0.0)))
|
export: package=org.slf4j.impl; uses:=org.slf4j
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j)(version>=1.6.1)(version<=1.6.1))
|
export: package=org.slf4j; uses:=org.slf4j.spi
com.springsource.slf4j.api [135.0]
import: (&(package=org.slf4j.spi)(version>=1.6.1)(version<=1.6.1))
|
export: package=org.slf4j.spi
com.springsource.slf4j.api [135.0]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3574)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1619)
SLF4J is OSGi friendly since a while so there is no need to use springsource based jar-s.
Install the newest slf4j-api jar with the implementation you would like to use!
How it works:
slf4j-api uses classes that are not in the jar and they are not imported. slf4j-xxximpl (like slf4j-simple) are fragment bundles where the host is slf4j-api so they will have a common classloader.
This means that you have to install an slf4j-api and slf4j-xxx together (if you install it runtime call a refresh on the container if necessary to have good wirings). This also means that slf4j cannot work with more implementations and it is also not a good idea to have multiple versions of slf4j-api in the same container.
Solution: Remove the springsource based jar and install the newest slf4j-api and impl jars into the container and after that call refresh if necessary.
Related
2.8 together with its cxf feature 3.3.5, with cxf-jaxrs which is installed as feature comes a dependency to Google Guava 20.0. I have my own project where I install a couple of jars via Karaf feature, among them a Google Guava 18.0. The bundle I want now to install has a Google Guava dependency for 18.0, however i get the following error:
Chain 1:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0)(!(version>=19.0.0)))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [253](R 253.0)]
Chain 2:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))
|
export: osgi.wiring.package=com.querydsl.core; uses:=com.google.common.collect
com.querydsl.core [com.querydsl.core [255](R 255.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [172](R 172.0)] Unresolved requirements: [[arcanite-core [269](R 269.0)] osgi.wiring.package; (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))]
In my imports for the project I have explicitly imported the 18.0 version:
<Import-Package>
...
com.google.common.collect;version="[18.0,19.0)",
*
<Import-Package>
How can I get rid of this conflict, is this really about having only one version of Guava in Karaf ( OSGI ), what am i doing wrong?
Ok that was a tricky one, as said the cxf-feature made up a dependecy to Guava 20.0.
Then installing my own feature with query-dsl and guvava 18.0 jar inside.
But the dependency querydsl to guava was not resolved according to maven, but according to the already existing guava in karaf so 20.0.
When i now install a bundle with query-dsl and guava 18.0 then there is the conflict.
In the end i removed 18.0 library from the feature and allowed a larger version range in my project:
...
com.google.common.collect;version="[18.0,23.0)",
*
And the conflict was gone, makes me wonder how would i specify such a dependency, here between querydsl and guava 18.0 in the feature.xml, if possible at all.
I work on a multi module maven project with osgi bundles deployed to karaf. We are observing intermittent bundle start-up issues in our test and production environments due to the below error, which is later resolved after restarting the karaf container:
Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve resource myBundle [myBundle [16](R 16.0)] because it is exposed to package 'javax.el' from resources javax.el-api [javax.el-api [236](R 236.0)] and com.sun.el.javax.el [com.sun.el.javax.el [212](R 212.0)] via two dependency chains.
Chain 1:
myBundle [myBundle [16](R 16.0)]
import: (&(osgi.wiring.package=javax.el)(version>=3.0.0)(!(version>=4.0.0)))
|
export: osgi.wiring.package: javax.el
javax.el-api [javax.el-api [236](R 236.0)]
Chain 2:
myBundle [myBundle [16](R 16.0)]
import: (&(osgi.wiring.package=com.sun.el)(version>=3.0.0)(!(version>=4.0.0)))
|
export: osgi.wiring.package: com.sun.el; uses:=javax.el
export: osgi.wiring.package=javax.el
com.sun.el.javax.el [com.sun.el.javax.el [212](R 212.0)] Unresolved requirements: [[myBundle [16](R 16.0)] osgi.wiring.package; (&(osgi.wiring.package=com.sun.el)(version>=3.0.0)(!(version>=4.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[10:org.apache.karaf.features.core:4.0.7]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[10:org.apache.karaf.features.core:4.0.7]
... 6 more
I went through these 2 related SO posts (Error starting bundle in karaf: "via two dependency chains" and Why are uses constraints violated when both chains end in the same bundle? ) but in my situation I am actually unable to determine where from the javax.el-api dependency is being introduced to myBundle. Our project uses Hibernate Validator, which requires the EL package from glassfish jar, so this is where the com.sun.el.javax.el package dependency is introduced. I was unable to determine where the javax.el-api dependency is being introduced from though. I tried checking the dependency tree using the below maven commands but to no avail.
mvn compile dependency:tree
mvn compile dependency:tree -D:verbose
mvn compile dependency:tree -D:verbose -Dincludes=javax.el
This is the dependency added for hibernate validator:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.el</artifactId>
<version>3.0.1-b08</version>
</dependency>
The karaf version being used is 4.0.7
Any help will be appreciated.
I have got the project for migration. Currently, version is CQ5.6. Maven build is deploying successfully. However, after build, bundles in osgi show in installed state. Two dependencies causing the issue.
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
I was getting an error earlier as below during build.
ERROR
[INFO] --- maven-bundle-plugin:2.3.4:bundle (default-bundle) # myPRJ-taglib ---
[ERROR] Error building bundle com.mypack.deewealth:myPRJ-taglib:bundle:1.0.0-SNAPSHOT : Unresolved references to [org.apache.felix.shell] by class
(es) on the Bundle-Classpath[Jar:dot, Jar:OSGI-INF/lib/recaptcha4j-0.0.8-kohsuke-1.jar, Jar:OSGI-INF/lib/commons-io-2.1.jar, Jar:OSGI-INF/lib/commons-
lang-2.4.jar, Jar:OSGI-INF/lib/crx-packagemgr-1.0.22.jar, Jar:OSGI-INF/lib/squeakysand-osgi-0.4.0.jar, Jar:OSGI-INF/lib/jsoup-1.6.1.jar, Jar:OSGI-INF/
lib/stax-api-1.0-2.jar, Jar:OSGI-INF/lib/org.apache.sling.settings-1.1.0.jar, Jar:OSGI-INF/lib/cq-compat-runmode-0.2.0.jar, Jar:OSGI-INF/lib/commons-c
ollections-3.2.1.jar, Jar:OSGI-INF/lib/squeakysand-jsp-0.4.0.jar, Jar:OSGI-INF/lib/squeakysand-commons-0.4.0.jar]: [org/apache/sling/settings/impl/Run
ModeCommand.class]
To solve this I added below dependancy in pom.xml, as we added in
Dependency
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.shell</artifactId>
<version>1.4.2</version>
<scope>provided</scope>
</dependency>
Under import statement.
<Import-Package>
....
....
org.apache.felix.shell
</Import-Package>
After that, build was successful, but bundle was in resolved state because of
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
Any suggestion, why this is causing the problem.
org.apache.felix.shell,version=[1.0,2) -- Cannot be resolved
mean that you are trying to use these felix packages from within AEM. However - there are no OSGi bundles in AEM that exports these packages.
You can download the bundle from maven repo and upload it into the AEM Felix console and use it.
OR you can create it as your parent pom dependency as one of module and wrap along with your project jar and use it.
To veify the availability of any package and dependencies use AEM Dependency finder.
I don't know CQ but I can explain why this happens in general. You had the error during build time because of missing dependency. You correctly solved it by adding the dependency which fixed your build. What happened behind the scenes is your bundle was updated with information that it needs (imports) org.apache.felix.shell,version=[1.0,2) package and that package will be provided by some other bundle at runtime.
Then at runtime the resolver got that information and tried to find a bundle that provides (exports) org.apache.felix.shell,version=[1.0,2) package. It couldn't find one and so the resolution failed and your bundle was left in installed (I believe that's what you meant to write instaed of resolved in your last sentence) state!
To solve that, you need to make sure org.apache.felix.shell,version=[1.0,2) package is available at runtime. I don't know CQ and how to install bundles in it but since you can install your own bundle I assume you can also install org.apache.felix.shell bundle the same way.
The shell jar you have installed is still unresolved as it depends on some jars that might not be present. You need to find the depth of all dependencies and resolve them.
I'm trying to use JackRabbit 2.11.1 to connect to a remote repo (using jackrabbit-jcr-rmi). The bundles run in JBoss Fuse 6.2, which has Apache Karaf 2.4 / Felix 4.4 under the hood. On startup i get the exception below.
If i try to use jackrabbit-bundle i get
"Missing Constraint: Import-Package: com.ibm.db2.jcc; version="0.0.0""
So i'm confused, is JackRabbit 2.x OSGi ready? or do i need to use Sling or Oak , or .... ?
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]
See also https://issues.apache.org/jira/browse/JCR-3917
I solved it with a horrible hack.
Embed the dependencies i need into my own jar.
Set the ContextClassLoader to the classloader of the providing class (what the SPI thing was supposed to do in the first place but did not work, probably because i needed to wrap more jars than the one i did ?).
So, in the maven-bundle-plugin i did:
<Embed-Dependency>jackrabbit-jcr2dav*,jackrabbit-jcr2spi*,jackrabbit-jcr-commons*;scope=compile;inline=false</Embed-Dependency>
And in my consuming 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);
I am using the following camel packages in my Maven project:
camel-core
camel-jms
camel-jaxb
camel-quartz
camel-bindy
camel-ftp
And when all these are using version 2.8.0 my server starts up fine and the app works ok. But if I update the camel version to anything higher like 2.10.0 then I get the following exception on startup and not sure which of these is causing this issue:
Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type converters because of: Cannot find any type converter classes from the following packages: [org.apache.camel.component.file.remote]
Any help would be much appreciated?
Maybe another library of your project is using a different version of camel.
You can check the camel dependency tree of your project with this maven command:
mvn dependency:tree -Dverbose -Dincludes=camel-core
In verbose mode, the dependency tree shows dependencies that were omitted for being a duplicate of another, conflicting with another's version and/or scope, and introducing a cycle into the dependency tree.
Here are some reference links:
https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html
https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html