Bundles in karaf failing due to "Bundle Exception: Uses constraint violation." - maven

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.

Related

Karaf OSGI How to resolve a two dependency chain conflict for Google Guava

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.

Maven (Tycho) cannot resolve OSGi Core bundle

I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The reason is that I need access to the "org.osgi.framework" package. I am using Maven (3.6) and Tycho (1.5.1) for building. The build platform runs Debian 10 and Java 11.
I get the following error:
Missing requirement: osgi.core 7.0.0.201802012106 requires 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it could not be found
However, if I remove the dependency I get the following error:
Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package; org.osgi.framework 1.7.0' but it could not be found
What is going wrong? How can I resolve this problem?
I get the following error:
Missing requirement: osgi.core 7.0.0.201802012106 requires 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it could not be found
The "companion jars" are not meant for runtime and since resolving is a runtime operation (even when performed during build, i.e. for deployment purposes) should not be included (and are therefore marked with the unresolvable requirement).
However, if I remove the dependency I get the following error:
Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package; org.osgi.framework 1.7.0' but it could not be found
This means you have no runtime framework available! Add a runtime dependency on the equinox framework (not intentionally being biased, but since you're using tycho I'm assuming eclipse/equinox landscape. If you have Apache Felix framework available to p2/tycho then use that if you like):
<dependency>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.osgi</artifactId>
<version>3.x.0</version>
<scope>runtime</scope>
</dependency>
// of course use tycho mechanism for above.

OSGI bundle dependency issue

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.

could found maven dependency

karaf#root> install -s mvn:com.thoughtworks.xstream/xstream/1.4.7
Bundle ID: 169
Error executing command: Error installing bundles:
Unable to start bundle mvn:com.thoughtworks.xstream/xstream/1.4.7:
Unresolved constraint in bundle xstream [169]:
Unable to resolve 169.0: missing requirement [169.0] osgi.wiring.package; (osgi.wiring.package=sun.misc)
i can not find the proper maven dependency for xstream ... I searched too many links but the result is same ... is there any alternative way to overcome this issue ... can i make maven bundle form JAR? if yes then how ?
i solved this problem through adding this missing class "sun.misc" in the config.properties file of karaf... As i got that "sun.misc" is the library of jdk that is why karaf could'nt use it so i add this class in config.properties file of karaf and the problem resolved.

BundleException: Unable to resolve module because it exports package 'org.slf4j.spi' and is also exposed to it from com.springsource.slf4j.api

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.

Resources