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

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.

Related

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.

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

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.

How to force my OSGI bundle to ignore a conflicted a bundle while resolving dependencies

I am using AEM 5.6.1. I am getting an exception with JAXB my bundle when a jax-b api 2.2.12 manually is installed in console. As JAX-b(2.1.0) is already provided internally in AEM by below bundle. This exception doesn't happen when the 2.2.12 is not present. Also, if jax-b 2.2.12 is installed after my bundle, no problems at all.
However this new version is being used by another bundle developed by a different vendor. Hence I can't remove this new bundle from felix console.
The system bundle which provides the original JAX-B 2.1.0
`<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.fragment.xml</artifactId>
<version>1.0.2</version>
</dependency>`
I was just wondering how could I force my bundle to ignore looking for jax-b 2.2.12 and take only the system default 2.1.0 version by some configuration using maven pom. Specifically in maven bundle plugin in the POM.
Activate method in my ABC class:
`#Activate
public void activate(ComponentContext ctx) throws JAXBException {
abcContext = JAXBContext.newInstance(ABC.class);
}`
Current Bundle plugin import package definition:
<Import-Package>
*;resolution:=optional
</Import-Package>
Exception:
16.03.2016 03:13:05.709 *ERROR* [Background Update foo.barsupport-bundle (606)] foo.barsupport-bundle [foo.bar.calendar.impl.CalendarEventParserImpl] The activate method has thrown an exception (javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by cqse-httpservice [25]]) javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.internal.bind.v2.ContextFactory not found by cqse-httpservice [25]]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:241)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:477)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:656)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:599)
at foo.bar.integration.calendar.impl.CalendarEventParserImpl.activate(CalendarEventParserImpl.java:33).
Any help would be really appreciated.
In general, your problem is that your bundle by default accept [2.0, 3.0) which is perfect for the Semantic Versioning (Major.Minor.BugFix). But, if your bundle use the newer version, and if it communicates with some of thoses classes to your framework which use an older version of that bundle, you can get those kind of ClassNotFoundException in Runtime.
The uses directive is created to make sure that if there is multiple compatible versions, and multiple importers, those importers will communicate between them with the same version. It generally occurs when a bundle exports packages where other packages imported by other. This is why a good practice is to have API bundle which doesn't export anything or Impl bundle that exports anything, it free you from the need of uses..
Try to use a version range when importing jaxb in your bundle:
<Import-Package>
javax.xml.bind;version="[2.1,2.2)"
*;resolution:=optional
</Import-Package>
This directive tell the osgi resolver to wire your bundle with the package javax.xml.bind with a version from 2.1 to 2.2, 2.2 excluded.

Karaf 3.0 is missing javax.validation requirement

I get this missing requirement:
osgi.wiring.package = javax.validation
in Karaf 3
I tried bundle:install -s mvn:javax.validation/validation-api/1.0.0.GA but it does not seem to install it correctly.
Any idea on how to resolve this missing requirement?
Karaf 3.0.1 introduced a new hibernate-validator feature which is part of the enterprise repository, which is available by default:
> feature-list|grep hibernate-validator
hibernate-validator | 5.0.3.Final | | enterprise-3.0.1 | Hibernate Validator support
> feature:info hibernate-validator
...
Feature contains followed bundles:
mvn:javax.validation/validation-api/1.1.0.Final
mvn:com.fasterxml/classmate/1.0.0
mvn:javax.el/javax.el-api/2.2.4
mvn:org.glassfish.web/javax.el/2.2.4
mvn:org.hibernate/hibernate-validator/5.0.3.Final
mvn:org.jboss.logging/jboss-logging/3.1.4.GA
The hibernate-validator adds a few more validators on top of those specified in the bean validation API.
Can you let me know the version of java that you are using, as well as the value of PROPERY JAVA_HOME.
Looks like you might be using Java 8. And I think it might not be supported at the present moment.
I had the same issue and switched to JDK1.7 and all the missing requirements errors for javax.* were resolved.
you must wrap javax validation because it's not a valid bundle
the valid command :
install wrap:mvn:javax.validation/validation-api/1.0.0.GA
Validation spec can be installed from various places. You can use apache bval together with geronimo specs:
mvn:org.apache.geronimo.specs/geronimo-validation_1.0_spec/1.1
mvn:org.apache.bval/org.apache.bval.bundle/0.5
Bval have couple of dependencies:
mvn:org.apache.commons/commons-lang3/3.1
mvn:common-beanutils/common-beanutils/1.8.3
Geronimo specs is OSGi ready and works properly as long as you have only one spec implementation.
If wrapping and hibernate-validator are not solved your problem you can try servicemix bundles
Apache ServiceMix :: Specs :: JSR 303 API 1.0.0
karaf side you should install bundle ..
>bundle:install mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jsr303-api-1.0.0/2.6.0
bundle 55
>start 55
>list
Also you should include package in project
<dependency>
<groupId>org.apache.servicemix.specs</groupId>
<artifactId>org.apache.servicemix.specs.jsr303-api-1.0.0</artifactId>
<version>2.6.0</version>
</dependency>
Packages
javax.validation
javax.validation.bootstrap
javax.validation.constraints
javax.validation.groups
javax.validation.metadata
javax.validation.spi
org.apache.servicemix.specs.locator

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