CODEWITHSUNDEEP
javaosgi
JerryCai
JerryCai

Reputation: 1693

How to get all jar paths used by OSGi?

I want to get all jar paths that I can search .class file in these jars. I wrote a function to search all the jars under App main folder but encountered a problem -- some jar bundles are existed but out of date and not used by OSGi, ex. xxxx_1.0.0.jar and xxxx_1.2.0.jar are both existed, but only 1.2.0 are used by OSGi. If I search in main folder, are of them will be in the result list.

So is there a way to get all the jar files which used by OSGi? Then I can filter out the jar files which not used. Thanks

Added: I tried to use this way to get all the Bundles absolute URL, but failed:

StringBuffer sb = new StringBuffer();
Bundle[] bundles = com.ibm.director.services.storage.debugtool.Activator.context.getBundles();
for (Bundle bundle : bundles) {
    java.net.URL url = bundle.getClass().getProtectionDomain().getCodeSource().getLocation();
    sb.append("File:" + url.getFile() + ", Path:" + url.getPath() + "\n");
}

But hundred times of following output repeated:

File:/opt/ibm/director/lwi/runtime/core/eclipse/plugins/org.eclipse.osgi_3.4.3.R34x_v20081215-1030-RCP20120203-1500.jar
File:/opt/ibm/director/lwi/runtime/core/eclipse/plugins/org.eclipse.osgi_3.4.3.R34x_v20081215-1030-RCP20120203-1500.jar, 
File:....

The number of used bundle is: 588, it might be correct, and we can get absolute Bundles path from the API but why they are all the same? How can I get the real path?

Upvotes: 1

Views: 921

Answers (2)

Peter Kriens
Peter Kriens

Reputation: 15372

Think bundles ... just do bundle.getResource( clazz.getName().replace('.','/')+".class")

Before you recompile, look in the bundle: "OSGI-OPT/src/" + clazz.getName().replace('.','/')+".java", the actual source code might be there.

Upvotes: 2

Philippe Marschall
Philippe Marschall

Reputation: 4604

BundleContext#getBundles() gives you all bundles. You can then compare symbolic names and versions. However just because you have both xxxx_1.0.0.jar and xxxx_1.2.0.jar that doesn't mean that xxx_1.0.0.jar is unused. There might be some other bundles present that require xxx_1.0.0.jar. Likewise just because a bundle isn't started doesn't mean it won't be started later. You do not want to reimplement the OSGi resolver. If you want to clean up a repository I would suggest you use an application provided by the vendor of the repository like GC Application in p2.

Upvotes: 3

Related Questions