[equinox-dev] Question about host extension points under OSGI

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Greetings,

I'm not a regular reader of this list, but a casual scan of the archive 
didn't find anything about this question, so I'm going to ask it of this 
group.  My apologies in advance if the answer is well-known.

I'm building some plugins that provide host extension points so that 
other plugins can register themselves as 'providers' for some basic apis 
provided by my plugins.  In one of my plugin 'start(BundleContext)' 
method, I define and call a routine called 'setupHostExtensionPoints()' 
to configure host extension points, as per the article (Notes on Eclipse 
Plugin Architecture):

http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html

Within my setupHostExtensionPoints, I have a piece of code that looks 
like this:

               ClassLoader loader = 
pluginDescriptor.getPlugin().getClass().getClassLoader();

This is used to get the classloader for the plugin (client) that is 
going to be using this host extension point.  Then this classloader is 
passed to a piece of code so that a client plugin class can be loaded 
(via the 'loader' classloader) for my (host) plugin...e.g.

               Class nsClass = loader.loadClass(nsClassName);
               Constructor cons = nsClass.getDeclaredConstructor(new 
Class[] { 
String.class,String.class,String.class,String.class,String.class});
               Namespace ns = (Namespace) cons.newInstance(new Object[] 
{nsName,nsInstantiatorClass,nsProtocol,nsVersion,nsData});
               // Now add to namespaces known
               IDFactory.addNamespace(ns);

In this way, client plugins can add support (i.e. their classes) for 
entirely new namespaces to my 'identity' plugin.

So what's the problem?  Well, the call to get the classloader (necessary 
to be able to load classes from the *client plugin's* codebase) depends 
upon the getting the IPluginDescriptor:

           IPluginDescriptor pluginDescriptor = 
extension.getDeclaringPluginDescriptor();

but this interface (IPluginDescriptor) and the method 
(getDeclaringPluginDescriptor()) are both deprecated now, because of the 
move to the OSGI plugin model...where references to plugins are not 
passed around 'freely'.  And there's no analog to 'getPlugin()' in the 
IExtensionPoint interfaces/classes.

But I don't need a reference to the actual plugin instance...I just need 
it's classloader.  Is access to another bundle's classloader provided in 
some other way?  If so, what is that access?  Is it considered protected 
as well?  If so, how do host extension point providers allow client 
plugins to have *their* classes loaded/bound to those host extension points?

Thanks for any info,

Scott