Find the OSGI bundle that exports a package? - osgi

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

Related

How to provide additional class for a package on OSGi system classpath for J2SE 1.8 profile

Inside ee.j2se-1.8 the package org.w3c.dom is included.
org.osgi.framework.system.packages = \
...
org.w3c.dom,\
...
org.osgi.framework.bootdelegation = \
...
org.w3c.*,\
org.xml.*,\
....
The bundle xml-apis_1.4.1.20140905-131237.jar contains the same package org.w3c.dom, but with one important class more ... ElementTraversal.class more.
So here my questions...
How can I provide the missing class inside my Equinox OSGi runtime?
You are suffering from the fact that people do not take packages seriously. We have a similar problem in the jta API. The version delivered by the VM is not identical to the version that is delivered as a special package.
The solution is to include the JAR with the extra packages on the class path where the framework resides. It looks like you're using bnd (good!) so this would look like:
-runpath: xml-apis__xml-apis;version="[1.4.1,2.0.0)"
If this had been a bundle with proper exports then you would have automatically gotten its exports as system packages. Looking at the packages in this bundle it seems all packages are already in the standard exports of the VM. However, if you have packages int his JAR that are not exported by the VM then you can add them as follows:
-runsystempackages: javax.xml.foo

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

Replacing classes/resources with an OSGi fragment - possible without including a jar in the fragment?

We want to replace certain resources in a host OSGi bundle by adding an OSGi fragment.
As I understand it, the resources included in an OSGi fragment are merely added to the classpath of the host bundle.
There is no guarantee that if the fragment is adding a resource that already exists in the host bundle,
the resource from the fragment will be loaded: it could also still be the host version.
In order to make sure the fragment version of the resource is loaded instead of the host version,
http://wiki.osgi.org/wiki/Fragment mentions it is possible to use the Bundle-ClassPath header to specify resources as "first"(preferred).
It gives patch.jar as an example:
Bundle-ClassPath: patch.jar,.
As mentioned there: "Since patch.jar is ahead of '.' it will allow classes to be preferentially loaded from the fragment instead of the host."
I could use this technique, but this means I first have to bundle my fragment resources in a separate jar and then include this jar in the fragment bundle.
Is there a way to preferentially load classes/resources from the fragment instead of the host without having to include a jar in the fragment?
You don't have to include a jar. You can instead use a "patch" directory and then put your classes in a patch directory in the fragment.
Ok, there are a couple of ways to accomplish what you want. As I understand it, after everything is done, you want to export packages from a library bundle except for the packages located in your patch bundle.
To accomplish this, in the Manifest.MF of your library bundle, specify the explicit packages you want to export instead of '.'. You can do this with a fragment so that you won't have to modify the original bundle. Then, do the same with your patch bundle.
Another option is to use the maven-bundle-plugin to "shade" (merge) the patch bundle and the library bundle together into a new bundle. As long as the patch bundle and he library bundle have different version numbers, this will also work. Many blogs will instruct you to use the maven-shade-plugin along with the maven-bundle-plugin for this option, but they are incorrect. You can definately perform shading with the maven-bundle-plugin.
For those that are still struggling, these are the exact steps that worked for me:
Create a fragment project with the resource/class you want to replace
In the fragment's build.properties, change source.. = src/ and output.. = bin/ to source.patch/ = src/ and output.patch/ = bin/
In the fragment's manifest, add patch/ to the bundle class-path
Example:
Let's say you have com.example.ui plug-in which has a com.example.ui.MessageDialog class that you want to replace.
Create a fragment project com.example.ui.fragment
Create the MessageDialog class in the com.example.ui package (not com.example.ui.fragment);
Edit the fragment's build.properties file like this:
source.patch/ = src/
output.patch/ = bin/
In the fragment's manifest add this:
Bundle-ClassPath: patch/
In the com.example.ui manifest change the bundle class-path:
Bundle-ClassPath: patch/,.

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.

How to troubleshoot java.lang.NoSuchMethodError?

I know that a java.lang.NoSuchMethodError means that the version of a class used for compiling is different from the version used at runtime. Usually, when I see this issue, I start the app.server in java -verbose mode, which tells me the jar file from which a class is loaded. If that jar file is not the one I intended to use, I know I'm using an incorrect version of the jar file.
Another approach I use, is to use javap to look at the method signatures of the class in the jar file I am using at runtime, to confirm that the jar does indeed contain the class with a different method signature.
I am seeing this error now in Karaf, an OSGi container and none of the above approaches are helping. java -verbose shows me the jar, javap shows me the method signature and the method signature is the same as that in the error stacktrace. In other words, I can see that the class from the jar being used at runtime does have the same method signature that the jvm says it cannot find.
Here is the exact stack trace, if it helps:
java.lang.NoSuchMethodError: org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/axiom/soap/SOAPModelBuilder;
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:179)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659)
Are there any other approaches I can/should use? Thanks for your help.
The Karaf commands exports [ids], imports [ids] and classes [ids] can used in combination with grep (each command has a --help option).
From the bundle throwing the error (with id N), imports N | grep org.apache.axiom.om will tell you which bundle it is actually importing that package from.
And approaching from the other side, exports | grep org.apache.axiom.om will list the bundles that export that package.
I'd expect you'll see more than one line from the exports and the import command will show incorrect version is being used.
You could also use java -verbose:class to see where classes are loaded from, which might show that the problematic class is loaded from a different bundle that you expected.

Resources