Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Bundle Ad-Hoc Classloading Options In 3.6, Revisited
Bundle Ad-Hoc Classloading Options In 3.6, Revisited [message #555182] Wed, 25 August 2010 14:01 Go to next message
Rob Hatcherson is currently offline Rob Hatcherson
Messages: 27
Registered: July 2009
Location: Fort Worth, TX, USA
Junior 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 08:12 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: Bundle Ad-Hoc Classloading Options In 3.6, Revisited [message #555386 is a reply to message #555182] Thu, 26 August 2010 09:28 Go to previous message
Rob Hatcherson is currently offline Rob Hatcherson
Messages: 27
Registered: July 2009
Location: Fort Worth, TX, USA
Junior Member
Paul,

I thought briefly about a similar approach a few days ago while wading through all the other mechanisms. It has the virtue of being the best of both worlds, by letting me still gather up contributors according to <whatever> criteria and still doing things the way Eclipse would like them to be done, so that may yet end up being how I do this.

It definitely feels like walking on thin ice to stick one's nose into the class loading machinery, since you can potentially foul up all kinds of things. I'm probably going to continue investigating those options anyway if for no other reason than to get a better understanding of all possibilities.

Thanks a lot for the feedback (and the re-route to the more appropriate forum).

Rob
Previous Topic:Synchronizing data in FormEditor
Next Topic:How to enable/disable a command on a view toolbar?
Goto Forum:
  


Current Time: Tue Jul 29 08:58:02 EDT 2014

Powered by FUDForum. Page generated in 0.01656 seconds