cannot run cxf in osgi xmlschema bundle missing (but it is installed) - osgi

I am trying to run a cxf bundle in karaf. It says that the package org.apache.ws.commons.schema is missing but the appropiate bundle is already installed (servicemix bundle)
I dont know why the dependency is not solved if the bundle 785 (xmlschema) is activated. Do I need to include something else or do I have some sort of configuration problem?
OSGi>features:install idb
Refreshing bundles org.springframework.jms (104)
Error executing command: Could not start bundle
mvn:org.apache.cxf/cxf-bundle-minimal/2.2.9 in feature(s)
cxf-bundle-minimal-2.6.0: Unresolved constraint in bundle
org.apache.cxf.bundle-minimal [832]: Unable to resolve 832.0:
missing requirement [832.0] package;
(&(package=org.apache.ws.commons.schema)(version>=1.4.0)(!(version>=2.0.0)))
OSGi>osgi:info 785
Apache ServiceMix Bundles: xmlschema-1.4.3 (785)
------------------------------------------------
OSGi>osgi:headers 785
Apache ServiceMix Bundles: xmlschema-1.4.3 (785)
------------------------------------------------
Manifest-Version = 1.0
Bnd-LastModified = 1237594240914
Tool = Bnd-0.0.255
Built-By = gnodet
Build-Jdk = 1.5.0_16
Created-By = Apache Maven Bundle Plugin
Bundle-Vendor = The Apache Software Foundation
Bundle-Name = Apache ServiceMix Bundles: xmlschema-1.4.3
Bundle-DocURL = http://www.apache.org/
Bundle-Description = This bundle simply wraps xmlschema-1.4.3.jar.
Bundle-SymbolicName = org.apache.servicemix.bundles.xmlschema
Bundle-Version = 1.4.3.1
Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion = 2
Import-Package =
javax.xml.namespace,
javax.xml.parsers,
javax.xml.transform,
javax.xml.transform.dom,
javax.xml.transform.sax,
javax.xml.transform.stream,
org.apache.ws.commons.schema;version=1.4.3,
org.apache.ws.commons.schema.constants;version=1.4.3,
org.apache.ws.commons.schema.extensions;version=1.4.3,
org.apache.ws.commons.schema.resolver;version=1.4.3,
org.apache.ws.commons.schema.utils;version=1.4.3,
org.w3c.dom,
org.xml.sax
Export-Package =
org.apache.ws.commons.schema.resolver;uses:=org.xml.sax;version=1.4.3,
org.apache.ws.commons.schema.utils;
uses:="org.apache.ws.commons.schema,
javax.xml.namespace,
org.w3c.dom";
version=1.4.3,
org.apache.ws.commons.schema;
uses:="org.xml.sax,
javax.xml.namespace,
org.w3c.dom,
javax.xml.transform,
org.apache.ws.commons.schema.extensions,
javax.xml.transform.dom,
javax.xml.transform.sax,
org.apache.ws.commons.schema.resolver,
org.apache.ws.commons.schema.utils,
javax.xml.parsers,
org.apache.ws.commons.schema.constants,
javax.xml.transform.stream";
version=1.4.3,
org.apache.ws.commons.schema.constants;
uses:=javax.xml.namespace;
version=1.4.3,
org.apache.ws.commons.schema.extensions;
uses:="org.apache.ws.commons.schema,
javax.xml.namespace,
org.w3c.dom";
version=1.4.3

The CXF version you use seems to be quite old. Can you test this with the most recent CXF version? Btw. What Karaf version are you using?

First of all, what is the state of bundle 785 (xmlschema-1.4.3) ?
If the state is resolved or active, it is ok; if it is only "installed", then there is a problem with it and the packages it exports are not available in the system.
Second, check who provides the packages imported by bundle 785. (org.w3c.dom etc)
You could have the following situation:
If bundle idb imports e.g. org.w3c.dom from one source, and xmlschema-1.4.3 imports them from another (e.g. different versions are available at the same time, or both the framework itself and some additional bundle provide it) then the framework won't resolve the idb bundle with the package from xmlschema-1.4.3, because this would lead to a ClassCastException later on.

Related

OSGI : maven wrapped bundle throws java.lang.ClassNotFoundException if it tries to access another wrapped bundle

As below dependencies are not OSGI-ready I wrapped them as follows :
<bundle>wrap:mvn:com.google.maps/google-maps-services/0.9.2</bundle>
<bundle>wrap:mvn:com.squareup.okhttp3/okhttp/3.13.1</bundle>
Seems like my first bundle can't access second bundle, although I included it in my imports as follows:
<Import-Package>okhttp3,*</import-Package>
I am getting :
Caused by: java.lang.NoClassDefFoundError: okhttp3/Authenticator
at com.google.maps.GeoApiContext$Builder.<init>(GeoApiContext.java:318)
at com.elavon.nabsd.creditsafe.beans.GooglePlacesAPIContext.<clinit>(GooglePlacesAPIContext.java:11)
at com.elavon.nabsd.creditsafe.beans.AddressParser.getAddress(AddressParser.java:35)
at com.elavon.nabsd.creditsafe.beans.AddressParser.dummyResponse(AddressParser.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:408)
at org.apache.camel.component.bean.MethodInfo$1.doProceed(MethodInfo.java:279)
at org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:252)
... 13 more
Caused by: java.lang.ClassNotFoundException: okhttp3.Authenticator not found by wrap_mvn_com.google.maps_google-maps-services_0.9.2 [1180]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1556)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1993)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 24 more
Manifest
Manifest-Version: 1.0
Bnd-LastModified: 1552097042208
Build-Jdk: 1.8.0_181
Built-By: c041356
Bundle-Blueprint: OSGI-INF/blueprint/address-parser-blueprint.xml
Bundle-Description: XXX
Bundle-DocURL: XXX
Bundle-ManifestVersion: 2
Bundle-Name: XXX
Bundle-SymbolicName: address-parser
Bundle-Vendor: XXX
Bundle-Version: 1.0.24
Created-By: Apache Maven Bundle Plugin
DynamicImport-Package: *
Export-package: com.squareup.okhttp3,okhttp3
Import-Package: okhttp3,com.fasterxml.jackson.annotation,com.google.maps
,com.google.maps.errors,com.google.maps.model,org.apache.camel.componen
t.jasypt,org.jasypt.encryption.pbe.config,org.osgi.service.blueprint;ve
rsion="[1.0.0,2.0.0)",org.slf4j,org.apache.camel.component.http4,org.ap
ache.camel.component.jackson,com.squareup.okhttp3
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.0.0.201509101326
wrap_mvn_com.squareup.okhttp3_okhttp_3.13.1 (1202)
--------------------------------------------------
Originally-Created-By = Apache Maven 3.6.0
Created-By = 1.8.0_181 (Oracle Corporation)
Manifest-Version = 1.0
Bnd-LastModified = 1552095323499
Generated-By-Ops4j-Pax-From = wrap:mvn:com.squareup.okhttp3/okhttp/3.13.1
Build-Jdk = 1.8.0_162
Built-By = jwilson
Automatic-Module-Name = okhttp3
Tool = Bnd-2.3.0.201405100607
Bundle-ManifestVersion = 2
Bundle-SymbolicName = wrap_mvn_com.squareup.okhttp3_okhttp_3.13.1
Bundle-Version = 0
Bundle-Name = wrap_mvn_com.squareup.okhttp3_okhttp_3.13.1
Require-Capability =
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
Export-Package =
okhttp3;uses:="javax.annotation,javax.net,javax.net.ssl,okio",
okhttp3.internal;uses:="javax.annotation,javax.net.ssl,okhttp3,okhttp3.internal.cache,okhttp3.internal.connection,okhttp3.internal.http,okhttp3.internal.http2,okio",
okhttp3.internal.annotations;uses:="javax.annotation,javax.annotation.meta",
okhttp3.internal.cache;uses:="javax.annotation,okhttp3,okhttp3.internal.io,okio",
okhttp3.internal.cache2,
okhttp3.internal.connection;uses:="javax.annotation,javax.net.ssl,okhttp3,okhttp3.internal.http,okhttp3.internal.http2,okhttp3.internal.ws",
okhttp3.internal.duplex,
okhttp3.internal.http;uses:="javax.annotation,okhttp3,okhttp3.internal.connection,okio",
okhttp3.internal.http1;uses:="okhttp3,okhttp3.internal.connection,okhttp3.internal.http,okio",
okhttp3.internal.http2;uses:="okhttp3,okhttp3.internal.connection,okhttp3.internal.http,okio",
okhttp3.internal.io;uses:=okio,
okhttp3.internal.platform;uses:="javax.annotation,javax.net.ssl,okhttp3,okhttp3.internal.tls",
okhttp3.internal.proxy,
okhttp3.internal.publicsuffix,
okhttp3.internal.tls;uses:=javax.net.ssl,
okhttp3.internal.ws;uses:="javax.annotation,okhttp3,okio"
Import-Package =
android.os;resolution:=optional,
android.util;resolution:=optional,
javax.annotation;resolution:=optional,
javax.annotation.meta;resolution:=optional,
javax.net;resolution:=optional,
javax.net.ssl;resolution:=optional,
javax.security.auth.x500;resolution:=optional,
okio;resolution:=optional,
wrap_mvn_com.google.maps_google-maps-services_0.9.2 (1180)
----------------------------------------------------------
Created-By = 1.8.0_181 (Oracle Corporation)
Manifest-Version = 1.0
Bnd-LastModified = 1552091296783
Generated-By-Ops4j-Pax-From = wrap:mvn:com.google.maps/google-maps-services/0.9.2
Tool = Bnd-2.3.0.201405100607
Bundle-ManifestVersion = 2
Bundle-SymbolicName = wrap_mvn_com.google.maps_google-maps-services_0.9.2
Bundle-Version = 0
Bundle-Name = wrap_mvn_com.google.maps_google-maps-services_0.9.2
Require-Capability =
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
Export-Package =
com.google.maps;uses:="com.google.gson,com.google.maps.errors,com.google.maps.internal,com.google.maps.model,okhttp3",
com.google.maps.errors,
com.google.maps.internal;uses:="com.google.appengine.api.urlfetch,com.google.gson,com.google.gson.stream,com.google.maps,com.google.maps.errors,com.google.maps.model,okhttp3",
com.google.maps.internal.ratelimiter,
com.google.maps.model;uses:=com.google.maps.internal
Import-Package =
com.google.appengine.api.urlfetch;resolution:=optional,
com.google.gson;resolution:=optional,
com.google.gson.stream;resolution:=optional,
javax.crypto;resolution:=optional,
javax.crypto.spec;resolution:=optional,
okhttp3;resolution:=optional,
okio;resolution:=optional,
org.slf4j;resolution:=optional
Wrapped bundles get the automatically discovered package dependencies as "optional", because there is no way to tell reliably whether some specific package will actually be required or not when using specific functionality provided by the bundle.
Hence, the existence of other bundles and their exported packages at the bundle resolving time determine, which packages are actually visible to the created class-loader of the resolved wrapped bundle.
In your case, the packages exported by bundle "okhttp3" where not available at the time the resolver searched for available package to import when resolving bundle "google-maps".
This in turn means that you need to make sure that either:
the bundle "okhttp3" is visible to the resolver at the time of resolving bundle "google-maps"
make sure that the required package imports are not "optional"
While the first option may seem easier, the second one is more reliable and flexible.
The wrap: protocol supports overwriting generated OSGi headers so that you can specify details to your needs. In our case, it would be:
<bundle>wrap:mvn:com.google.maps/google-maps-services/0.9.2$overwrite=merge&Import-Package=okhttp3,okio,*;resolution:=optional</bundle>
(untested and only based on docs, though)
Notice
Before using the wrap protocol, please have a look whether the desired library has already been OSGi-fied by some other project. One very good start is to have a look at the Bundles made available by the Apache ServiceMix project (which provides a okhttp3 Bundle):
https://repo1.maven.org/maven2/org/apache/servicemix/bundles/

bundle will not start when bouncy castle is imported

I am trying to add bouncy castle as a service provider to my java product running on apache karaf.
When I am trying to start the bundle which imports bouncy castle I get an error message
java.lang.Exception: Could not start bundle mvn:com.xxx.yyy.zzz/docsservice/1.0.0-SNAPSHOT/war in feature(s) server-docs-1.0.0-SNAPSHOT: Unresolved constraint in bundle docs [245]: Unable to resolve 245.0: missing requirement [245.0] osgi.wiring.package; (&(osgi.wiring.package=org.bouncycastle.jce.provider)(version>=1.51.0))
at org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:472)
In the pom file I imported the package org.bouncycastle.jce.provider and I added bouncycastle as a dependency.
Also, i made all the changes described on this page,
http://karaf.apache.org/manual/latest/users-guide/security.html, see below
I put provider jar in lib/ext
I Modified the etc/config.properties configuration file to add the following property
org.apache.karaf.security.providers = xxx,yyy
org.apache.karaf.security.providers = org.bouncycastle.jce.provider.BouncyCastleProvider
I provided access to the classes from those providers from the system bundle so that all bundles can access those. I did this by modifying the org.osgi.framework.bootdelegation property in the same configuration file:
org.osgi.framework.bootdelegation = ...,org.bouncycastle*
On some forum I found another suggestion so I modified
*org.osgi.framework.system.packages.extra = * in the config.properties as well and I added here packages exported from bouncycastle
Nonetheless I wasn't able to load the bundle successfully. I looked at all the bundles loaded by karaf and none of them was exporting bouncy castle package.
What am I missing here? How can I make the bundles to start?
By adding the package to the boot delegation you made it available like java.* packages. For these you do not need an Import-Package. So one way would be to remove the Import-Package for it in your bundle. You should rather explore though if you can work without boot delegation.
Please try to remove the boot delegation and add the package to
org.osgi.framework.system.packages.extra = org.bouncycastle.jce.provider
This adds the package to the packages the system bundle exports. It should then be wired to your bundle.

Karaf missing classes in bundles

I am deploying httpclient-4.3.4.jar in deploy folder of karaf. In terminal when I use command find-class HttpClients, nothing is getting listed. When use keyword find-class HttpClient, I get only follwing classes loaded for httpclient bundle. Since some of the classes are missing I am getting java.lang.NoClassDefFoundError: org/apache/http/impl/client/HttpClients in one of my dependent bundles.
I need to know whey some classes are not available. If it is our own bundle, we can specify imports and exports to control the classes which we need to expose. But for external jars, why this is happening?
httpclient (202)
org/apache/http/HttpClientConnection.class
org/apache/http/client/HttpClient.class
org/apache/http/client/params/HttpClientParams.class
org/apache/http/client/utils/HttpClientUtils.class
org/apache/http/impl/AbstractHttpClientConnection.class
org/apache/http/impl/DefaultHttpClientConnection.class
org/apache/http/impl/SocketHttpClientConnection.class
org/apache/http/impl/client/AbstractHttpClient.class
org/apache/http/impl/client/AutoRetryHttpClient.class
org/apache/http/impl/client/ContentEncodingHttpClient.class
org/apache/http/impl/client/DecompressingHttpClient.class
org/apache/http/impl/client/DefaultHttpClient.class
org/apache/http/impl/client/SystemDefaultHttpClient.class
First, is it a valid OSGi bundle, without the required manifest entries and the right Package-Exports/Imports this won't work.
If you just drop it in the deploy folder it might get autowrapped, but this isn't always working. It's better to either take an existing Bundle or do install with:
osgi:install wrap:mvn:groupID/artifactID/version
All of this is also documented in the Karaf User Manual.
The installed bundle can be started with
start ID
where ID is the ID of the bundle just installed.
EDIT:
You definitely need to wrap the bundle in question, since it isn't a OSGi bundle yet.
So in your case do:
install wrap:mvn:org.apache.httpcomponents/httpclient/4.3.4
after the bundle is installed:
start ID
If you do a bundle:header after that you'll get a nice header definition.
The find class does show the HttpClient class in this bundle:
karaf#root()> find-class HttpClients
wrap_mvn_org.apache.httpcomponents_httpclient_4.3.4 (78)
org/apache/http/impl/client/HttpClients.class

Unable to wire proper bundle with my own bundle in wso2 app server

I am using wso2 Application Server 5.1.0.
I have deployed my own bundle having name demo-service which contains import-package definition in its manifest as below:
>Bundle-SymbolicName = demo-service
Import-Package = javax.sql,org.apache.commons.dbcp;version="[1.4,2)"
I tried to diagnose the most popular "uses conflict" in OSGi world for my case and I found that commons-dbcp_1.4.0.wso2v1.jar and commons-dbcp-1.4.jar both were converted to OSGi bundle by container and exported their packages with version "0.0.0" which can be observed from the output below:
>osgi> packages org.apache.commons.dbcp
org.apache.commons.dbcp; version="0.0.0"<commons-dbcp_1.4.0.wso2v1 [49]>
compass_2.0.1.wso2v2 [60] imports
org.wso2.carbon.core_4.1.0 [256] imports
org.wso2.carbon.registry.core_4.1.0 [377] imports
org.wso2.carbon.tenant.mgt_2.1.0 [434] imports
synapse-commons_2.1.1.wso2v3 [528] imports
synapse-core_2.1.1.wso2v3 [529] imports
org.apache.commons.dbcp; version="0.0.0"<commons_dbcp_1.4_1.0.0 [57]>
According to the requirement of my demo-service bundle it's not able to find
org.apache.commons.dbcp;version="[1.4,2)"
Is there any way to export the packages of commons-dbcp-1.4.jar after it gets converted from non-osgi bundle to osgi bundle because I need to make sure that my demo-service bundle should wire with commons-dbcp-1.4.jar..
In brief, any version of thirdparty jar I put in WSO2_HOME\repository\components\lib folder container exports it with version="0.0.0" .. which discourages the main concept for classloading of OSGi
please suggest if any workaround is possible in this case .. :)
Thanks ..
When a version is not specified while exporting packages OSGi defaults to version 0.0.0. In this case as it's automatically converting to osgi bundle it might not be having version explicitly specified. Sometimes this also helps to ensure that multiple versions of packages are not present.
In your case as you need to use the packages in the bundle put in repository\components\lib folder you could manually specify the version. The OSGi-fied bundles of the jars you put in repository\components\lib can be found in repository\components\dropins folder. Inside that bundle you will find the OSGi manifest file. In the manifest file manually specify the versions for the required packages under Export-Package category as follows.
org.apache.commons.dbcp;version=1.4.1
Then on startup, it would use these bundles and you should be able to export packages with specified version.

using cxf in osgi: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found

I am trying to publish some web services (using EndpointImpl.publish()) but I am gettings this error:
Provider org.apache.cxf.jaxws.spi.ProviderImpl not found
the cxf-bundle is installed:
[ 79] [Active ] [Created ] [ 50] Apache CXF Bundle Jar (2.4.3.fuse-01-02)
an extract of the osgi:headers shows the imported package
Import-Package =
javax.jws,
javax.persistence;version="[1.1,2)",
javax.servlet;version="[2.5,3)",
javax.xml.bind,
javax.xml.bind.annotation,
javax.xml.bind.annotation.adapters,
javax.xml.datatype,
javax.xml.namespace,
javax.xml.parsers,
javax.xml.transform,
javax.xml.transform.stream,
javax.xml.validation,
javax.xml.ws;version="[2.2,3)",
javax.xml.ws.soap;version="[2.2,3)",
javax.xml.ws.wsaddressing;version="[2.2,3)",
org.apache.commons.lang;version="[2.5,3)",
org.apache.commons.logging;version="[1.1,2)",
org.apache.cxf.jaxws;version="[2.4,3)",
org.apache.cxf.jaxws.spi;version="[2.4,3)", <--- imported
org.apache.cxf.ws.addressing;version="[2.4,3)",
org.apache.felix.gogo.commands;version="[0.10,1)",
org.apache.openjpa.enhance;version="[2.2,3)",
org.apache.openjpa.util;version="[2.2,3)",
org.osgi.framework;version="[1.5,2)",
org.osgi.service.blueprint;version="[1.0.0,2.0.0)",
org.springframework.beans.factory.xml;version="[3.0,4)",
org.springframework.context;version="[3.0,4)",
org.springframework.context.support;version="[3.0,4)",
org.w3c.dom,
org.xml.sax
Require-Bundle =
org.apache.cxf.bundle
I am not sure what else I need to do.
in case it is important. the container is a karaf 2.2.7
to address pooh's answer:
1- cxf-bundle is exporting this package: org.apache.cxf.jaxws.spi;version="2.4.3.fuse-01-02"
2- bundle was started. the error was during runtime.
3- the manifest was created using maven-bundle-plugin which should create the entire list
4- the error happen while creating a webservice endpoint:
TopologyIFPortType impl = new TopologyWS();
String addressTopology = "http://localhost:" + port
+ "/nsp/webservice/topology";
topologyEndpoint = (EndpointImpl) Endpoint.create(impl);
topologyEndpoint.getFeatures().add(new WSAddressingFeature());
topologyEndpoint.publish(addressTopology);
the complete trace:
javax.xml.ws.spi.FactoryFinder$ConfigurationError: Provider org.apache.cxf.jaxws.spi.ProviderImpl not found
at javax.xml.ws.spi.FactoryFinder$2.run(FactoryFinder.java:130)
at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:220)
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:124)
at javax.xml.ws.spi.FactoryFinder.access$200(FactoryFinder.java:44)
at javax.xml.ws.spi.FactoryFinder$3.run(FactoryFinder.java:211)
at javax.xml.ws.spi.FactoryFinder.doPrivileged(FactoryFinder.java:220)
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:160)
at javax.xml.ws.spi.Provider.provider(Provider.java:43)
at javax.xml.ws.Endpoint.create(Endpoint.java:41)
at javax.xml.ws.Endpoint.create(Endpoint.java:37)
at org.opennaas.extensions.idb.webservice.WebServiceHolder.startTopology(WebserviceControl.java:78)
at org.opennaas.extensions.idb.webservice.WebServiceHolder.start(WebserviceControl.java:60)
at org.opennaas.extensions.idb.webservice.WebserviceControl.startWebservices(WebserviceControl.java:32)
at org.opennaas.extensions.idb.shell.StartWebservices.doExecute(StartWebservices.java:16)
at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)
at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.karaf.shell.console.jline.Console.run(Console.java:240)
at java.lang.Thread.run(Thread.java:679)
The version of CXF you use seem to be quite old. You should try with the current release 2.6.1. In 2.6 a lot of OSGi improvements were introduced.
You can install it using:
features:chooseurl cxf 2.6.1
features:install cxf
Don't worry, OSGi gives you full access to the information which bundle uses which package etc. You only have to know how to ask the system to give you the info you need for debugging the problem.
Unfortunately I am not familiar with karaf console commands, I am working more with ProSyst's mBeddedServer OSGi framework, but since all this is standard in OSGi, I can tell you what to look for and you can find the needed commands in karaf.
So, check the following:
1. Is Apache cxf bundle successfully installed? Is it in the "active" state?
(from your posting it seems that it is)
What is the version of the org.apache.cxf.jaxws.spi package that it exports?
This is different from the cxf bundle version!!!
In order to see the package version, look inside the manifest of the cxf bundle, and look for the Export-package header.
Is your bundle installed and started successfully? Is it in the active state?
If the error "Provider not found" appears during starting of your bundle, then your dependencies are not matching the provided packages from the cxf bundle, see point 2.
If, however, the error appears during runtime, it could have several causes:
You haven't imported all needed packages in your manifest. Try using analysis tools which can generate the manifest for you based on your source code.
or:
The code which does the publishing is located e.g. on the system classpath and uses the system classloader, which in OSGI due to modularity and security reasons doesn't have access to the bundle classloaders.
Check what is provided by the system classpath instead of as OSGi bundles. Anything there which uses Class.forName or other reflection methods won't work in the modular OSGi framework.
There are also other possibilites, but you'll need to provide more info. Was there an exception stack trace? What classes are involved in this piece of code and where on the classpath are they located? etc.

Resources