OSGi does not require class loaders to be backed by jar files. Jars are the typically distribution (and install) format for bundles. But once installed, the framework is free to manage the bundle contents in anyway (e.g. put them in a database.) OSGi also does not require bundles to be in jar format. Many OSGi implementations support installing bundles in directory format or even VM implementation proprietary formats (e.g. J9 JXE).
So I don't see that there is any way to map a bundle's classloader onto a set of jar files for that bundle. A better problem to look at for OSGi, would be what bundles are installed but not used. This could be determined by analyzing that state of the installed bundles (are they started? will they be started at some startlevel?) and the dependencies between bundles (does some other bundle depend upon this bundle?). This analysis could find "orhpan" bundles which can safely be uninstalled. My main point is that in OSGi you should not think in terms of jars (and classloaders which reference them) but in terms of bundles (and which bundles reference them). -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Kyrill Alyoshin <[EMAIL PROTECTED]> To: OSGi Developer Mail List <[email protected]> Date: 2008-02-28 12:11 Subject: Re: [osgi-dev] OSGI ClassLoader discover process Hi Mirko and Stuart, Sorry for not replying to this any earlier. I was tied up with other things... Basically, I've created an open-source project called 'loosejar': http://loosejar.googlecode.com http://weblogs.java.net/blog/emcmanus/archive/2008/02/do_i_really_nee.html Loosejar is a utility Java agent that looks at all classes loaded in the JVM, maps them out to their respective classloaders, discovers what jars are available to each classloader, and then it easily determines which jars are not used. The "loose" part in the algorithm is the discovery of available jars. As you can see from the blog, ClassLoader.getResources < http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResources%28java.lang.String%29 >("META-INF/MANIFEST.MF") is the only "known" way to get the full transitive closure of all available jars. There is an RFE to enable jar discovery for OSGi classloaders, and now I am trying to figure out how to do it. Again, the question is: If I have an instance of an OSGi ClassLoader how do I know what jars are available to it to load from. Presumably the first step is to look in META-INF/MANIFEST.MF... To find a solution that would work for all OSGi implementations would be beyond ideal, but I am ready to settle just for Equinox for the moment. Thanks so much for your help! -Kyrill Mirko Jahn wrote: > Hi Kyrill, > > I am not sure, what you are trying to accomplish, but if you want to > make resources in your nested jars available in the class path of your > bundle class loader, you can just add these jars in your Manifest.mf > file with the Bundle-Classpath header (see OSGi Spec v4.1 Sec. > 3.2.1). > > If you need to get a resource within the bundle, look at the Bundle > class, you get from the BundleContext of your activator. There you'll > find three different methods (depending on your requirements), which > can serve you by that (getResource, getEntry or findEntries - OSGi > Spec v4.1 Sec. 3.8.6). > > The URL you mentioned (used by Equinox) is an implementation detail > (like the name of the ClassLoader you mentioned), which is not part of > the standard. Each vendor can implement this in any imaginable format, > so do not rely on that, but use the official api's. You can find more > about that in the section about URL Handlers in the spec. > > I hope that helps. > > -- Mirko > > On Fri, Feb 22, 2008 at 4:54 AM, Kyrill Alyoshin <[EMAIL PROTECTED]> wrote: > >> Hi gurus, >> >> I am trying to figure out a way, given an "OSGI-enabled" classloader >> like, for example, >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader to discover all >> available jars that this classloader can see (as list of URLs or URIs). >> >> It is a fairly trivial exercise in "normal" Java. :-) You can call >> ClassLoader#findResources("META-INF/MANIFEST.MF"), and you'd get back a >> transitive closure of all jars in the following format: >> jar:file:/foo/bar/baz.jar!/META-INF/MANIFEST.MF. >> >> Well, with org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader, I >> get the following response from this method (as a sample): >> bundleresource://105:1/META-INF/MANIFEST.MF. >> >> How would I parse it to get to the actual jars? >> >> What about in general? How is an OSGI classloader supposed to query its >> resource bundles? >> >> Thanks so much for your help! >> >> -Kyrill >> >> >> >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://www2.osgi.org/mailman/listinfo/osgi-dev >> >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://www2.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ OSGi Developer Mail List [email protected] https://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://www2.osgi.org/mailman/listinfo/osgi-dev
