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
