Karaf 3.0 is missing javax.validation requirement - osgi

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

Related

How to fix CVE-2019-8457 vulnerability in Spring Boot

How to fix CVE-2019-8457 vulnerability in Spring Boot application, since none of my known dependencies includes SQLite3 in Spring Boot 2.6.6, jdk18-slim docker image
CVE-2019-8457
db5.3:5.3.28+dfsg1-0.8
HIGH
SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-of-bound read in the rtreenode() function when handling invalid rtree tables.
use alpine version of container images which mostly does not have high and critical vulnerabilities
Please inspect the dependency tree of your project to check if there is a transitive dependency defined on sqlite3. You may not be using sqlite3 directly in the project dependencies, there is a chance that some other library has defined it as a dependency.
For maven.
mvn dependency:tree
For gradle.
gradle dependencies
Once you find it, use exclusion pattern to exclude the older version of sqlite3 and explicitly declare a dependency of sqlite3 with the fixed version of sqlite3 version.

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.

How to resolve CVEs in spring-batch-core 4.0.1.RELEASE?

I noticed that I cannot create an issue on the spring-batch github and I could not create a topic on the Spring forum so I was redirected here.
I have this in my pom.xml file as explained on Spring.io's Batch tutorial
<dependency>
<groupId>org.springframework.batch</groupId>
<artifactId>spring-batch-core</artifactId>
<version>4.0.1.RELEASE</version>
</dependency>
And when I run the mvn dependency-check:check I see these issues
spring-tx-5.0.0.RELEASE.jar
CVE-2018-1199 - upgrade spring framework to latest 4.x
spring-batch-core-4.0.1.RELEASE.jar
CVE-2014-0225 - upgrade spring mvc - added it and latest 4.x
CVE-2015-5211 - upgrade springframework 4.x
CVE-2016-5007 - upgrade springframework 4.x
CVE-2014-3578 - upgrade springframework 4.x
CVE-2014-3625 - upgrade springframework 4.x
I ran mvn dependency:build-classpath -Dmdep.outputFile=cp.txt the offending jars above are located in my classpath. Then ran 'mvn dependency:tree` but did not see the offending jars.
mvn dependency:tree 2>&1 | egrep -i 'batch-core|spring-tx'
I tried googling some of the core CVEs which said to upgrade spring-mvc which I don't even have in my project but I explicitly defined it anyway. My spring version is set to the latest 4.x and even upgrading to 5.x still throws the vulnerability because spring-batch-core's latest version is still vulnerable.
Am I doing something wrong in my pom file?
To start, none of those CVEs apply directly to Spring Batch or the spring-batch-core jar file. They are all related to Spring Framework and Spring MVC. Also, every one of those CVEs has been mitigated in the specified patch versions.
If you have confirmed that your POM is bringing in the correct, non-vunlerable, version of Spring Framework, this is a case of a false positive and you'll need to configure whatever tool you're using to address this. If the artifact you are building as a result of the build process includes a vulnerable version of Spring Framework (or related components), then you do have an issue with your POM. We can help, but we need to see the POM in order to do so.

CXF - ClassCastException (SEIStub/ClientProxy) in Equinox

I am getting following exception inside Equinox OSGI :
Getting java.lang.ClassCastException: com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy
Please advise.
It looks like you accidently use the jax-ws stack that is part of the jdk instead of CXF. I guess the reason is an incorrect deployment of CXF in your OSGi runtime.
You will need to not export the jax-ws API packages from the framework and instead install the jax-ws API from servicemix bundles. You can try to install Apache CXF in Apache Karaf to see how the correct deployment should look like.
To set the packages to be exported by the framework use the framework property org.osgi.framework.system.packages. See also Apache Felix configuration. Unfortunately there is no option to remove a package from the exported packages. If you use this option then you need to specify all packages that the framework exports. The default can be found in the felix jar in a property file default.properties.

Karaf development

Im currently develop bundles for karaf and have some questions...
I wrote a bundle/webservice based on cxf, I try to deploy it in karaf but it could not start that bundle because it could not resolve some packages e.g.
org.osgi.framework.BundleException: Unresolved constraint in bundle org.springframework.aop [56]: Unable to resolve 56.0: missing
requirement [56.0] package; (&(package=org.aopalliance.aop)(version>=1.0.0)(!(version>=2.0.0)))
so here is a question, this package dependency comes from spring-aop (3.1.0.RELEASE), so where is the problem? what dependency is missing? how can I solve such problems?
In that case i did not clearly understand the development process. should i deploy all missing bundles in deploy? because i would like to keep thirdparty libs spereated from my developed bundles. And what bundles i have to deploy? Is it a trial and error process? Is there a common way to let maven do the dependency stuff?
I discovered a folder "system" and read on the docu that it is a repository like maven, is it for the features?
I had for test cases a karaf with some pre deployed bundles and put my webservice bundle into it, but again execeptions...
Caused by: java.lang.ClassNotFoundException: javax.servlet.http.HttpServlet
What dependency is missing?
I already read the tutorial about camel and karaf, but it did not explain the deployment stuff, so could anyone suggest me a good tutorial?
Thanks!
Chris
Short answer
Scroll down to the bit referring to "camel-cxf" and run the two commands features:addurl and features:install. I have a feeling this will resolve all your problems.
spring-aop
On Karaf console type:
exports | grep org.aopalliance.aop
I think you'll see lines like:
XX org.aopalliance.aop; version=3.1.0.RELEASE
So while the spring-aop bundle has the right packages they're the wrong version, the range being requested is >=1.0.0 and <2.0.0, so 3.1.0 doesn't satisfy that.
Deploying/Installing
You can drop bundles into ${karaf.home}/deploy or use the console.
You can install maven bundles from the Karaf console with:
install -s mvn:groupId/artifactId/version/packaging/classifier
Where -s starts the bundle and packaging/classifier are optional.
You can find a lot of OSGi ready maven dependencies here http://ebr.springsource.com/repository/app/ - I had a quick look but your spring aop dependency is very old, what version of CXF are you using?
Read up about Karaf features - they're basically XML files that list suites of bundles that can be installed. Very useful for deploying large numbers of bundles and they can be installed into a maven repository.
There are some standard features available in Karaf, try:
features:install war
This will give you a jetty webcontainer and may resolve your ClassNotFoundException: javax.servlet.http.HttpServlet as long as it's the right version
Camel also has a features file which probably sort all your issues, try this:
features:addurl mvn:org.apache.camel.karaf/apache-camel/2.9.0/xml/features
features:install camel-cxf
Tutorials
There's quite a bit available, some on http://karaf.apache.org and http://fusesource.com but also take a look at the PDF manual that comes in the Karaf distribution.
Always beware that info may be out-of-date
Please post your MANIFEST.MF file. I think you didn't not mention the tag in maven-bundle-plugin dependency.

Resources