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.
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
My question is similar to this one but I am using the Maven bundle plugin to achieve the same end result.
I am building a bundle that contains a persistence.xml file and I have found that the maven-bundle-plugin automatically generates the following headers in the manifest:
Require-Capability:osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl,
Require-Capability: osgi.extender;osgi.extender=aries.jpa,
Require-Capability: osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=jdbc/test)"
This in itself is not a problem however I am using Karaf and I want to deploy this and other bundles and Karaf features in one single feature of my own. When I do this it fails because the OSGi is unable to fulfil the capability osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl even though I specify the openjpa feature to be installed at the same time. I have discovered that I can get around this issue by changing effective:=active to resolution:=optional
To build my bundle I've tried the following Maven plugin configuration:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.3.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>com.example
</Export-Package>
<Include-Resource>
META-INF/persistence.xml=${project.build.directory}/classes/META-INF/persistence.xml,
{maven-resources}
</Include-Resource>
<Meta-Persistence>META-INF/persistence.xml</Meta-Persistence>
<Require-Capability>
osgi.service;resolution:=optional;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl,
osgi.extender;resolution:=optional;osgi.extender=aries.jpa,
osgi.service;resolution:=optional;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=jdbc/test)"
</Require-Capability>
</instructions>
</configuration>
</plugin>
However I get the same issue as in the linked question above i.e. duplicated requirements in the manifest.
I also see from a link on the above question that a change was made to bnd (bnd issue #1364) but this appears to only work for annotations? Is there a way to configure the Maven plugin to prevent duplicated requirements?
Update #1
My example code is available here at GitHub (karaf_features branch):
https://github.com/jtkb/jpatest/tree/feature/karaf_features
It consists of 3 modules but only 2 are of interest for this issue, simple and simple-datasource
simple is the 'persistence unit' and contains the persistence.xml. It is also the bundle in which the 'awkward' (yet real requirements) <Require-Capability> headers are generated.
simple-datasource provides the datasource to the persistence unit and contains a Karaf feature to install simple, simple-datasource bundles and all the required 3rd party bundles (via Karaf features). The feature XML contains:
<feature name="simple-datasource" description="simple-datasource" version="1.0.0.SNAPSHOT">
<feature version="4.1.1">jdbc</feature>
<feature version="2.6.0">jpa</feature>
<feature version="2.4.1">openjpa</feature>
<feature version="1.0.1">pax-jdbc-mariadb</feature>
<bundle>mvn:com.javatechnics.jpa/simple-datasource/1.0.0-SNAPSHOT</bundle>
<bundle>mvn:com.javatechnics.jpa/simple/1.0.0-SNAPSHOT</bundle>
</feature>
So installing my feature in Karaf I get this error:
Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=simple-datasource; type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; filter:="(&(osgi.identity=simple-datasource)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
[caused by: Unable to resolve simple-datasource/1.0.0.SNAPSHOT: missing requirement [simple-datasource/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=com.javatechnics.jpa.simple; type=osgi.bundle; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; resolution:=mandatory
[caused by: Unable to resolve com.javatechnics.jpa.simple/1.0.0.SNAPSHOT: missing requirement [com.javatechnics.jpa.simple/1.0.0.SNAPSHOT] osgi.service; objectClass=javax.persistence.spi.PersistenceProvider; javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl; effective:=active]]
The error to me almost feels like a circular reference issue but I cannot see how.
Inspecting the header of the simple bundle:
simple (59)
-----------
Bnd-LastModified = 1513115007378
Build-Jdk = 1.8.0_144
Built-By = kerry
Created-By = Apache Maven Bundle Plugin
Manifest-Version = 1.0
Meta-Persistence = META-INF/persistence.xml
Tool = Bnd-3.2.0.201605172007
Bundle-Blueprint = OSGI-INF/blueprint/blueprint.xml
Bundle-ManifestVersion = 2
Bundle-Name = simple
Bundle-SymbolicName = com.javatechnics.jpa.simple
Bundle-Version = 1.0.0.SNAPSHOT
Export-Service =
com.javatechnics.jpa.dao.BookServiceDao;ServiceManager=Blueprint;name=
BookServiceDao
Provide-Capability =
osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name=test,
osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name=test,
osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name=test,
osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name=test
Require-Capability =
osgi.service;effective:=active;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;objectClass=javax.persistence.spi.PersistenceProvider,
osgi.extender;osgi.extender=aries.jpa,
osgi.service;effective:=active;filter:=(osgi.jndi.service.name=jdbc/test);objectClass=javax.sql.DataSource,
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.5))
Export-Package =
com.javatechnics.jpa;uses:="com.javatechnics.jpa.dao,javax.persistence";version=1.0.0,
com.javatechnics.jpa.dao;uses:=com.javatechnics.jpa;version=1.0.0
Import-Package =
com.javatechnics.jpa,
com.javatechnics.jpa.dao,
javax.persistence;version="[1.1,2)",
org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
If you know that a bundle, let’s call it xyz, provides the PersistenceProvider service then you can write one additional bundle that simply does this:
Require-Bundle: xyz; bundle-version="[...)"
Provide-Capability: osgi.service;
objectClass=javax.persistence.spi.PersistenceProvider;
javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;
effective:=active
This essentially augments bundle xyz with a capability that will resolve the requirement in your bundle, at the cost of adding an otherwise useless bundle.
This is still something of a workaround but is better than removing a real requirement from a bundle.
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.
Getting below error when im trying to run a OSGI bundle. Any clues will be really appreciate.
ERROR: Bundle com.springsource.org.apache.axis [15] Error starting mvn:
org.apache.axis/com.springsource.org.apache.axis/1.4.0 (
org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve
bundle revision com.springsource.org.apache.axis [15.0] because it is exposed to
package 'javax.activation' from bundle revisions com.springsource.javax.activation
[14.0] and org.apache.felix.framework [0] via two dependency chains.
Chain 1:
com.springsource.org.apache.axis [15.0] import: (&(osgi.wiring.package=
javax.activation)(version>=1.1.0)(!(version>=2.0.0))) | export:
osgi.wiring.package=javax.activation com.springsource.javax.activation [14.0]
Chain 2:
com.springsource.org.apache.axis [15.0] import: (&(osgi.wiring.package=
javax.xml.soap)(version>=0.0.0)) | export: osgi.wiring.package=javax.xml.soap;
uses:=javax.activation export: osgi.wiring.package=javax.activation
org.apache.felix.framework [0])
org.osgi.framework.BundleException: Uses constraint violation.
Unable to resolve bundle revision
com.springsource.org.apache.axis [15.0] because it is exposed to package
'javax.activation' from bundle revisions com.springsource.javax.activation [14.0]
and org.apache.felix.framework [0] via two dependency chains.
Chain 1:
com.springsource.org.apache.axis [15.0] import: (&(osgi.wiring.package=javax.activation)(version>=1.1.0)(!(version>=2.0.0))) | export: osgi.wiring.package=javax.activation com.springsource.javax.activation [14.0]
Chain 2:
com.springsource.org.apache.axis [15.0] import: (&(osgi.wiring.package=javax.xml.soap)(version>=0.0.0)) | export: osgi.wiring.package=javax.xml.soap; uses:=javax.activation export: osgi.wiring.package=javax.activation org.apache.felix.framework [0] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3980) at org.apache.felix.framework.Felix.startBundle(Felix.java:2037) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) at java.lang.Thread.run(Thread.java:745)
Remove the com.springsource.javax.activation bundle from your list of bundles.
If you need this special javax.activation bundle because of a special version, you'd need to make sure your own Imports are correct for the version.
Now that you are using the com.springsource.* bundles, those are pretty "OLD" and not maintained anymore I'd suggest to switch over to:
A) The official jars (like javax.activation) where the latest version is already a OSGi ready bundle
B) use ServiceMix wrapped bundles, the Apache ServiceMix Team provides a lot of OSGi ready bundles which aren't available from the originators.
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.