[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Question about host extension points under OSGI


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):


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

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,