We’ve encountered an issue with DM Lambda (1.1.1) where a bundle’s stop method is not being called when the bundle is stopped. I have an executable jar that contains a simple example of this issue. The example contains two custom bundles, one is using the standard DM syntax, where stop is being called as expected. The second custom bundle uses the new DM Lambda syntax and the Activator code is included below. This second bundle (org.syntech.examples.dmlambda) does not result in stop being called.
I have to think I’m just missing something obvious, but try as I might, I could not get the DM Lambda enabled bundle’s stop method to be called. Any help or guidance would be appreciated. We really like the new DM Lambda syntax and would like to use it going forward.
Example: simple activator using DM Lambda syntax, which does not call the “stop” method as expected. I’ve tried using the default and specifying the callbacks explicitly, nothing seems to work.
#Override
protected void init(BundleContext ctx, DependencyManager dm) throws Exception {
component(comp -> comp.impl(ExampleServiceUsingDmLambda.class)
.start("start")
.stop("stop")
.provides(ExampleServiceUsingDmLambda.class));
}
Following are the bundle versions contained in example JAR.
____________________________
Welcome to Apache Felix Gogo
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (5.6.10)|5.6.10
1|Active | 1|osgi.core (6.0.0.201403061837)|6.0.0.201403061837
2|Active | 1|Apache Felix Log Service (1.0.1)|1.0.1
3|Active | 1|Apache Felix Metatype Service (1.1.6)|1.1.6
4|Active | 1|Apache Felix Configuration Admin Service (1.8.16)|1.8.16
5|Active | 1|Apache Felix Dependency Manager (4.4.1)|4.4.1
6|Active | 1|org.apache.felix.dependencymanager.lambda (1.1.1)|1.1.1
7|Active | 1|Apache Felix Gogo Command (1.0.2)|1.0.2
8|Active | 1|Apache Felix Gogo Runtime (1.0.10)|1.0.10
9|Active | 1|Apache Felix Gogo Shell (1.0.0)|1.0.0
10|Active | 1|Apache Felix Remote Shell (1.2.0)|1.2.0
11|Active | 1|Apache Felix Dependency Manager Shell (4.0.6)|4.0.6
12|Active | 1|org.syntech.examples.dmlambda (1.0.0)|1.0.0
13|Active | 1|org.syntech.examples.dmstandard (1.0.0)|1.0.0
I also have an executable JAR and example project I can send that illustrates the issue. Any help or guidance would be appreciated.
Your example seems correct, but there is a bug in the org.apache.felix.dependencymanager.lambda 1.1.1 version.
I just fixed it (see the felix JIRA issue).
I also attached the patch in the jira issue which you can find here.
Related
we are using Quarkus with gRPC and some internal library that also uses the same protobuf data. So the dependency graph looks as follows:
quarkus-project
|
+--> lib
| |
| +--> my-protocol.proto
|
+--> my-protocol.proto
Our current solution is a maven artifact (my-protos) that wraps the my-protocol.proto and also includes the generated sources from that.
As Quarkus also needs the raw *.proto file to generate Mutiny wrappers around it, we also include my-protocol.proto via git submodule, s.t. we end up with the following structure:
quarkus-project
|
+--> lib
| |
| +--> my-protos
| |
| +--> my-protocol.proto
| +--> <generated sources>
|
+--> <git submodule> my-protocol.proto
|
+--> <mvn exclude> my-protos // are generated by quarkus again
The compiler checks that the classes to be generated from this proto are already present. So we had to exclude the dependency my-protos via maven dependency management.
Works inside IDE, all classes are present.
BUT as soon as we run Quarkus in dev mode (mvn quarkus:dev), the QuarkusClassLoader throws a ClassNotFoundException when we access a protobuf-generated class inside of the library-code. Checking the stacktrace, we see that the class we are trying to load is a banned dependency. We assume this is caused by the <exclude> in the pom.
Accessing the same class from code that is witten inside the quarkus-project, we do NOT see the exception.
So our best guess is that we are currently dealing with different classloaders (see [1]). The classloader, which is responsible for loading the libseems to have the banned dependency, the other one not.
This explanation is confirmed by running quarkus in production mode (where only the system classloader is used) and there we do not have the banned dependency problem there.
Please send help :)
[1] https://quarkus.io/guides/class-loading-reference
I am writing an extension to a Java application called ZAP. The extension is a fat/uber jar that has the Equinox bundle (org.eclipse.osgi) inlined. Additional bundles are also included in this jar, within a sub-directory bundles. The OSGi framework is being launched as outlined in How To Embed OSGi.
I'm trying to get Felix GoGo shell to work, following the steps outlined via Eclipse's "Console Shell" documentation. It specifies the following required bundles:
org.apache.felix.gogo.command
org.apache.felix.gogo.runtime
org.apache.felix.gogo.shell
org.eclipse.equinox.console
In addition to Equinox / org.eclipse.osgi. Since Equinox is not on the class path, I set org.osgi.framework.system.packages.extra configuration to the Export-Package value specified by Equinox's bundle, visible here.
Once the framework is in the ACTIVE state, I see the following stack trace in Eclipse (or via the command line outside of Eclipse):
Starting OSGi framework...
OSGi framework state: 32
gogo: MalformedURLException: unknown protocol: bundleresource
java.net.MalformedURLException: unknown protocol: bundleresource
at java.net.URL.<init>(URL.java:593)
at java.net.URL.<init>(URL.java:483)
at java.net.URL.<init>(URL.java:432)
at java.net.URI.toURL(URI.java:1089)
at org.apache.felix.gogo.shell.Shell.readScript(Shell.java:209)
at org.apache.felix.gogo.shell.Shell.source(Shell.java:192)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:109)
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:497)
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
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.felix.gogo.shell.Activator.run(Activator.java:75)
at java.lang.Thread.run(Thread.java:745)
It seems the Equinox URL handlers are not being used by GoGo. I noticed the following packages related to them were not in Equinox's Export-Package:
org.eclipse.osgi.storage.url
org.eclipse.osgi.storage.url.bundleresource
org.eclipse.osgi.storage.url.bundleentry
So I also included those in the org.osgi.framework.system.packages.extra package list. That didn't help.
The bundles are installed and started without any obvious errors otherwise.
How do I make GoGo utilize Equinox's custom URL handlers?
Update 1: Maybe Red Herring
In random troubleshoot I wanted to execute the final shaded jar as outlined here. I copied both the original org.eclipse.osgi bundle and the shaded jar in the same directory. There's a configuration/config.ini specifying the bundles to load.
Executing the stock bundle brings up the console:
$ java -cp ~/.p2/pool/plugins/org.eclipse.osgi_3.11.0.v20160121-2005.jar org.eclipse.core.runtime.adaptor.EclipseStarter -console
osgi> ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.11.0.v20160121-2005
1 ACTIVE org.apache.felix.gogo.runtime_0.10.0.v201209301036
2 ACTIVE org.apache.felix.gogo.command_0.10.0.v201209301215
3 ACTIVE org.apache.felix.gogo.shell_0.10.0.v201212101605
4 ACTIVE org.eclipse.equinox.console_1.1.200.v20150929-1405
osgi> exit
Really want to stop Equinox? (y/n; default=y)
Executing the shaded jar, not so much:
java -cp semiotics-alpha-1.zap org.eclipse.core.runtime.adaptor.EclipseStarter -console
java.lang.NullPointerException: A null service reference is not allowed.
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:617)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:299)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:231)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:208)
This could be a total red herring... I'm very ignorant on OSGi, this being my first hands-on experience with it. However, I would expect the shaded jar to execute no differently than the stock Equinox jar. Since I don't understand why there's a difference I'm gonna dig there for lack of any better spots to dig...
Update 2: Equinox on Classpath Works Around Issue
I added the Equinox bundle to ZAP's classpath via its lib directory and removed it from being inlined into the extension jar. Doing this and adjusting the ServiceLoader.load call to not include a class loader (defaulting to system class loader) works:
Starting bundle: org.apache.felix.gogo.shell_0.10.0.v201212101605 [1]
Starting bundle: org.eclipse.equinox.console_1.1.100.v20141023-1406 [2]
Starting bundle: org.apache.felix.gogo.command_0.10.0.v201209301215 [3]
Starting bundle: org.eclipse.emf.ecore_2.11.2.v20160208-0816 [4]
Starting bundle: org.eclipse.emf.common_2.11.1.v20160208-0816 [5]
Starting bundle: org.apache.felix.gogo.runtime_0.10.0.v201209301036 [6]
osgi> ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.11.0.v20160121-2005
1 ACTIVE org.apache.felix.gogo.shell_0.10.0.v201212101605
2 ACTIVE org.eclipse.equinox.console_1.1.100.v20141023-1406
3 ACTIVE org.apache.felix.gogo.command_0.10.0.v201209301215
4 ACTIVE org.eclipse.emf.ecore_2.11.2.v20160208-0816
5 ACTIVE org.eclipse.emf.common_2.11.1.v20160208-0816
6 ACTIVE org.apache.felix.gogo.runtime_0.10.0.v201209301036
osgi>
The underlying issue might be how the jar is being inlined, possibly related to the MANIFEST.MF file. Possibly related, I now don't need to supply a value for org.osgi.framework.system.packages.extra.
I'm going to leave this question unanswered since the original point was to include the OSGi library as a shaded artifact. Maybe bndtools can help?
OK, it seems the lack of a descriptive META-INF/MANIFEST.MF was the culprit:
Removed (jar uM...) then updated (jar um...) the shaded jar's MANIFEST.MF to be a copy of Equinox's manifest, modifying the Bundle-Version number to end in 1766 versus 1700.
Removed Equinox from ZAP's classpath
Then I loaded the extension as is. GoGo shell starts:
osgi> 13177 [AWT-EventQueue-0] INFO org.parosproxy.paros.control.Control - New Session
ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.10.102.v20160118-1766
1 ACTIVE org.apache.felix.gogo.runtime_0.10.0.v201209301036
2 ACTIVE org.eclipse.emf.common_2.11.1.v20160208-0816
3 ACTIVE org.apache.felix.gogo.shell_0.10.0.v201212101605
4 ACTIVE org.eclipse.equinox.console_1.1.100.v20141023-1406
5 ACTIVE org.apache.felix.gogo.command_0.10.0.v201209301215
6 ACTIVE org.eclipse.emf.ecore_2.11.2.v20160208-0816
osgi>
I see the system bundle ends in the same modified version number, so it's honoring the added MANIFEST.MF. So the underlying issue was an incomplete system bundle manifest. Copying an existing one (Equinox's) works well enough. It also works for a straight commandline test:
$ java -cp semiotics-alpha-1.zap org.eclipse.core.runtime.adaptor.EclipseStarter -console
osgi> exit
Really want to stop Equinox? (y/n; default=y) y
Dunno if I'll use this approach or not. At least I know what I need to do if I want to use this approach.
I am trying to deploy a simple feature into a branded Karaf 4.0.2 which brings a bundle with a JAXB Specification:
<?xml version="1.0" encoding="UTF-8"?>
<features name="my-feature" xmlns="http://karaf.apache.org/xmlns/features/v1.3.0">
<feature name="my-javaee-api" version="6.0-5" install="auto">
<bundle>mvn:org.apache.geronimo.specs/geronimo-jaxb_2.2_spec/1.0.1</bundle>
</feature>
</features>
It fails with the following error message:
2015-12-22 13:38:07,218 | ERROR | a0a-abc5141ad81f | FeatureDeploymentListener
| 43 - org.apache.karaf.deployer.features - 4.0.2 | Unable to install features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=my-javaee-api; type=karaf.feature; version="[6.0.0.5,6.0.0.5]";
filter:="(&(osgi.identity=my-javaee-api)(type=karaf.feature)(version>=6.0.0.5)(version<=6.0.0.5))"
[
caused by: Unable to resolve my-javaee-api/6.0.0.5:
missing requirement [my-javaee-api/6.0.0.5] osgi.identity; osgi.identity=org.apache.geronimo.specs.geronimo-jaxb_2.2_spec;
type=osgi.bundle; version="[1.0.1,1.0.1]"; resolution:=mandatory
[
caused by: Unable to resolve org.apache.geronimo.specs.geronimo-jaxb_2.2_spec/1.0.1:
missing requirement [org.apache.geronimo.specs.geronimo-jaxb_2.2_spec/1.0.1] osgi.wiring.package;
filter:="(&(osgi.wiring.package=javax.xml.namespace)(version>=1.0.0))"
]
]
I wondered how it could miss javax.xml.namespace because it's a part of OSGi-Framework. So I checked if that package is really missing:
admin#root()>package:exports | grep javax.xml.namespace
javax.xml.namespace | 0.0.0 | 0 | org.eclipse.osgi
And voila - here's the root of the problem - the version. For a comparison I checked how it looks on a stock karaf:
karaf#root()> package:exports | grep javax.xml.namespace
javax.xml.namespace | 0.0.0 | 0 | org.apache.felix.framework
javax.xml.namespace | 1.4.0 | 0 | org.apache.felix.framework
It uses Felix and has a proper version 1.4.0. My first thought was that the branded karaf uses Equinox as default OSGi-Framework and switching it to Felix would fix that. But a look inside karaf/etc/config.properties has disproved that thought (it looks exactly like stock):
karaf.framework=felix
karaf.framework.equinox=mvn\:org.eclipse.birt.runtime/org.eclipse.osgi/3.10.2.v20150203-1939
karaf.framework.felix=mvn\:org.apache.felix/org.apache.felix.framework/5.2.0
Now I reached an impasse and don't know how to resolve my problem. Any ideas?
Unfortunately I cannot contact people who branded karaf at the moment because they are already at christmas vacation ¯\_(ツ)_/¯
Make sure that your custom distribution doesn't change the config.properties.
If it does make sure that the org.osgi.framework.system.packages.extra
does contain that version for javax.xml.namespace;version=1.4,
Usually if you want to override certain properties for Karaf you can put those changes into the custom.properties
The exports from the OSGi Framework are controlled by the configuration properties org.osgi.framework.system.packages and org.osgi.framework.system.packages.extra. These are appended at runtime to form the system bundle exports.
It seems that in your "stock" version of Karaf (not sure what that means but I'll just use your term) somebody has added javax.xml.namespace;version=1.4.0 to one of those configuration properties. If you are able to do the same in the other version of Karaf then things should work.
How do I find the bundle that exports a package?
I am using felix and I have a string like "com.test", how do I know which bundle exports that package?
I don't want to use PackageAdmin as it has been deprecated, and I don't really want to get the Export-Package header for each bundle and parse it.
Any ideas?
It sounds like you want to do this programmatically, not at the Gogo shell ... at least I'll assume that from wording of your question.
There is no real way to say "which bundle" exports a given package since there can be many bundles exporting any given package and that package can be in use from many bundles by many bundles. If you have a specific bundle and you want to know which bundle provides package com.test to it, you can get the importing bundle's wiring Bundle.adapt(BundleWiring.class) and then use BundleWiring.getRequiredWires() to get the providers of all of the bundle's dependencies.
From there you just need to find the wire of osgi.wiring.package namespace for the package you want, then the provider of that wire will be a BundleCapability of a BundleRevision of the bundle you are interested in.
Have you tried:
exports | grep com.test ?
Recent versions of the Apache Felix OSGi console include a "dependency finder" plugin which lists the bundle(s) that export a given package or class. There are some screenshots at http://www.6dlabs.com/blog/dklco/2012-05-04/new-cq-55-dependency-finder (which mention CQ5 but the plugin does not depend on that).
That's useful at the admin level, and if you need to find that out in code you could have a look at that plugin's source code, see https://issues.apache.org/jira/browse/FELIX-3045
A quick solution is to iterate over the bundles, list the id and the export package header.
g! each (bundles) { echo ($it bundleId) (($it headers) get Export-Package) }
Note that you need to put spaces around the { and }! This prints for each bundle, its id and its Export-Package header. You can put this in a cmd:
g! exports= { each (bundles) { echo ($it bundleId) (($it headers) get Export-Package) } }
You can then use it easier with grep:
g! exports | grep webconsole
12 org.apache.felix.webconsole;version="3.3.0";uses:="javax.servlet,javax.servlet.http,org.osgi.framework",org.apache.felix.webconsole.bundleinfo;version="1.0.0";uses:="org.osgi.framework",org.apache.felix.webconsole.i18n;version="1.0.0";uses:="org.osgi.framework"
true
The official command for exported packages is inspect
g! inspect cap osgi.wiring.package
However, the output is very messy and hard to grep. However, if you know the package name then you can ask (deprecated) Package Admin.
g! r=servicereference org.osgi.service.packageadmin.PackageAdmin
....
g! pa=service $r
org.apache.felix.framework.PackageAdminImpl#2c7b40e3
g! $pa exportedpackages org.osgi.framework
org.osgi.framework; version=1.10.0
org.osgi.framework; version=1.9.0
org.osgi.framework; version=1.10.0
org.osgi.framework; version=1.9.0
g! each ($pa exportedpackages org.osgi.framework) { $it exportingbundle }
0|Active | 0|org.apache.felix.framework (0.1.0.SNAPSHOT)
Unfortunately, the Package Admin methods are overloaded and Gogo picks the first one that matches, otherwise it would be a lot easier :-(
If you have the set of bundles then the bnd command line can be useful. You can install it here.
You can then do:
$ bnd find -e "com.example*" jars/*.jar
or
$ bnd grep -e "com.example*" jars/*.jar
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.