With the current OSGi specification one way I can see doing this is to make all bundles supplying META-INF/.resources a fragment bundle of the main bundle using getResources(). This should make all resouces from the fragments available to the host as if they were part of the host. The problem with dynamic imports is you only get wired to a single exporter of the resource and you do not really have much of a choice on which one you get wired to. Although you could use some matching attributes to scope down the list of possible supplies, but this still does not help you get the resource from multiple suppliers.
If you are using Equinox you could use the buddy classloading mechanism.
Search Eclipse help for Eclipse-BuddyPolicy for more information.
There is ongoing discussions within OSGi for how to solve these types of
issues in a future version the specification, but that does not help you
now :)
Tom
From: [EMAIL PROTECTED]
To: [email protected]
Date: 12/16/2007 06:37 AM
Subject: [osgi-dev] classLoader.getResources("META-INF/.resource")
Hi,
I am little stuck with osgi while loading resources. My problem is to load
all "META-INF/.resource" resources from all exporting bundles in osgi
runtime. But classLoader.getResources("META-INF/.resource") returns empty
enumeration. Bundle where this is done is a legacy library converted to
Osgi plugin. Maximum I can do to legacy bundle is to change the manifest.
It does many Class.forName(), So i have put dynamic import as * there that
solves many class loading problem. All bundles that is having
META-INF/.resource is exporting META-INF package. There is also a bundle
that does not have .resource but exports META-INF for some other resource.
Unfortunately my legacy bundle gets wired to this bundle when when
getResources is done. Hence its returning empty enumeration. Had it been
wired to one of the .resource containing bundle atleast enumeration would
not been empty, though it would have returned only one.
I am kinda stuck, please help me.
-Rajesh
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
