Bundle Ad-Hoc Classloading Options In 3.6, Revisited [message #555182] |
Wed, 25 August 2010 18:01 |
Rob Hatcherson Messages: 33 Registered: July 2009 Location: Fort Worth, TX, USA |
Member |
|
|
The general topic of bundle classloading has been addressed many times, so apologies in advance for bringing it up again. Web info on this topic often applies to older versions of Eclipse, and it can be time-consuming to weed out the old from the new. At this point I'm fishing for advice that will keep me from running toward dead ends and/or pursuing options for which there are improved alternatives under 3.6.
Assume I have defensible reasons for needing my RCP plug-in to load ViewPart subclasses from an ad-hoc classpath, so that for all intents and purposes those ViewPart subclasses appear as through they were a built-in part of my plug-in:
MYCLASSPATH=<using some existing dynamic mechanism, assemble a classpath where ViewPart subclasses can be found>
Eclipse/Equinox <- allows ad-hoc ViewPart subclasses loaded by MyRcpPlugin to be added to windows/pages
MyRcpPlugin <- loads ViewPart subclasses from MYCLASSPATH so they appear to have come through the bundle's classloader
A custom classloader to load the classes of interest is easy enough; what I'm after are recommended ways to inject this into the bundle classloading mechanism, under the assumption that pre-building a RCP plug-in that already includes the ViewPart subclasses of interest is not an option (I may be able to do this in the future, but for now I can't).
There appear to be several mechanisms in 3.6 that *might* do what I want, including but not limited to adapter hooks, bundle proxy class loaders, and fiddling with OSGi parent classloaders. However, the discussion is esoteric, and sometimes is accompanied by words like "but we don't recommend that you do this" etc.
Adding on-the-fly contributions to the extension registry seems to be working ok. If I can settle on a decent approach to deal with the classloading issue - assuming it's even possible through public/approved mechanisms - then the rest of what I'm after should fall into place
Any advice?
|
|
|
Re: Bundle Ad-Hoc Classloading Options In 3.6, Revisited [message #555358 is a reply to message #555182] |
Thu, 26 August 2010 12:12 |
|
Rob Hatcherson wrote:
> The general topic of bundle classloading has been addressed many times,
> so apologies in advance for bringing it up again. Web info on this
> topic often applies to older versions of Eclipse, and it can be
> time-consuming to weed out the old from the new. At this point I'm
> fishing for advice that will keep me from running toward dead ends
> and/or pursuing options for which there are improved alternatives under
> 3.6.
>
> Assume I have defensible reasons for needing my RCP plug-in to load
> ViewPart subclasses from an ad-hoc classpath, so that for all intents
> and purposes those ViewPart subclasses appear as through they were a
> built-in part of my plug-in:
>
> MYCLASSPATH=<using some existing dynamic mechanism, assemble a classpath
> where ViewPart subclasses can be found>
>
> Eclipse/Equinox <- allows ad-hoc ViewPart subclasses loaded by
> MyRcpPlugin to be added to windows/pages
> MyRcpPlugin <- loads ViewPart subclasses from MYCLASSPATH so they
> appear to have come through the bundle's classloader
>
> A custom classloader to load the classes of interest is easy enough;
> what I'm after are recommended ways to inject this into the bundle
> classloading mechanism, under the assumption that pre-building a RCP
> plug-in that already includes the ViewPart subclasses of interest is not
> an option (I may be able to do this in the future, but for now I can't).
>
> There appear to be several mechanisms in 3.6 that *might* do what I
> want, including but not limited to adapter hooks, bundle proxy class
> loaders, and fiddling with OSGi parent classloaders. However, the
> discussion is esoteric, and sometimes is accompanied by words like "but
> we don't recommend that you do this" etc.
>
> Adding on-the-fly contributions to the extension registry seems to be
> working ok. If I can settle on a decent approach to deal with the
> classloading issue - assuming it's even possible through public/approved
> mechanisms - then the rest of what I'm after should fall into place
>
> Any advice?
>
I've re-routed this to equinox, they have a greater understanding of the
OSGi framework and classloading
The only suggestion I have: once you know your classpath, why not
assemble a bundle on the fly (you don't have to jar it up) and then use
BundleContext/PackageAdmin to load it?
the MANIFEST.MF is simple to create, as well as a plugin.xml.
Bundle-ClassPath can refer to jars that exist elsewhere on the system
using the external: scheme
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
|
Powered by
FUDForum. Page generated in 0.03745 seconds