[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Question about host extension points under OSGI
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Fri, 04 Jun 2004 11:52:24 -0700
- Delivered-to: firstname.lastname@example.org
- Organization: Composent, Inc.
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
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
Within my setupHostExtensionPoints, I have a piece of code that looks
ClassLoader loader =
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
Namespace ns = (Namespace) cons.newInstance(new Object
// 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 =
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
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,