Eclipse as we know is a great implementation of plugin-architecture.
We decouple different components of a system into bundles.
plugin-architecture is very simplistic in nature, highly extensible and modular at the cost of a tricky class-loading policy.
Actually Eclipse is a story of several class-loaders.
It iniataites a chain of class loaders to load the plug-ins lazily as specified in component-specific manifest.mf files.
If we understand its class-loading policy and learn some tricks, then we can make different third-party jars talk to each other and avoid infamous 'ClassNotFound Exception'.
The immediate parent of a plug-in class loader is the Eclipse Boot Class Loader (providing access to boot.jar). The parent is the standard java system class loader which terminates the chain. The Application Class-loader which loads classes from the system's CLASSPATH is not part of the chain.
That's why while loading product components, Eclipse does not look into Classpath in contrast to any other java-based client applications.
On start-up, the eclipse platform builds a shadow of all the plugins by reading all the manifest files into a plug-in registry.
Whenever a plugin com.xyz.myProduct is started by Eclipse Application Class,
the class-loader for com.xyz.myProduct takes-off.
If com.myProduct.xyz tries to access any class from another plugin com.myProduct.abc,
Eclipse invokes the Plug-in Class-loader coresponding to com.myProduct.abc.
That's the essence of Eclipse OSGi.
Q1. How to use third-party applications while building and running my product ?
Its of no use to specify third-party jars in classpath.
While building the application com.myProduct, we should bundle all the required jars in a single plugin (com.myProduct.library) and expose the apis of the bundled log4j, jpox, xstream etc.
Q2. How a third-party jar (log4j.jar) can see the classes from com.myProduct.xyz.jar during runtime ?
Lets assume com.abc.myProduct plugin logs messages using log4j.
So during runtime, log4j needs to see the classes from com.myProduct.abc plugin
This can be achieved by registering log4j with Eclipse-Buddy Policy and specifying com.abc.myProduct as a buddy of log4j.
# log4j Manifest.MF
Bundle-Name: org.apache.log4j
Bundle-Version: 1.2.13
...
Eclipse-BuddyPolicy: registered
# myplugin Manifest.MF
Bundle-Name: com.abc.myProduct
Bundle-Version: 1.0.0
Requires-Bundle: org.apache.log4j,...
Eclipse-RegisterBuddy: org.apache.log4j
If anyone registers with log4j as its buddy, and log4j needs to find a class com.abc.myProduct.MyComponent then it will check all the buddies before throwing "ClassNotFound" Exception
Q3. How can users integrate third-party jars with myProduct plugins on-the-fly ?
Lets see how users can actually hack eclipse configuration files to integrate required jars on-the-fly.
>> say user has installed a plugin com.magicScript which allows him to program using any script including jruby. But the product plugin doesn't ship the jruby jars i.e. does not adopt any of the above mechanisms.
So user have to add JRUBY_MOME in eclipse.ini. Now when eclipse will start up it will set jruby home in the path.
Lets assume the com.magicScript plugin already depends on a plugin com.magicScript.library containing a lib folder.
Next the jruby.jar needs to be placed inside the lib folder and the location lib\jruby.jar needs to be specified in the manifest.mf of com.magicScript.library.
Finally, starting eclipse with -clean -Intialization option will automatically first set Jruby path and then invoking magicScript perspective will trigger the classLoader for the bundle com.magicScript.library which in turn will load jruby classes from the jar (as specified in manifest.mf).
Thus user will be able to code/compile/run jruby.
This same trick can be used if we want the user to dynamically specify a DB driver jar and connect to a db using a plugin already installed in his environment.
Say com.myProduct.dbExplorer plugin will load classes from the jar to be specified by users during runtime.
(4) So far we depend only on Eclipse Bundle-ClassLoader and we configure eclipse in such a way (either development-time / runtime) that all required jars will be loaded by the classloader of the bundle in which jars are packed.
But what if we need to access a class which can not be loaded by the bundle-classloader ?
We need to set certain jars in custom classloader so the classes bundled in the jar can be loaded on demand !
A typical scenario is com.xyz.MyProduct.library contains scriptDebugger.jar (some 3rdparty jar) whose api need to be invoked during runtime and the api class will access some class of jruby.jar (may be specified by user during runtime) which can't be packed inside the product.
//The follwoing piece-of-code should be part of the com.xyz.myProduct.ScriptManager to load classes from jruby jar that user will specify during runtime.
// gather the names and loacation of jars as provided by user through preference page after product is deployed.
String[] jarslist = DynamicJarLoader.getThirdPartyJars();
URL[] jarURLs = new URL[jarslist.length];
JarFileLoader newLoader = new JarFileLoader(jarURLs);
for (int i = 0; i < jarslist.length; i++) {
newLoader.addFile (jarslist[i]);
}
class JarFileLoader extends URLClassLoader
{
public JarFileLoader (URL[] urls)
{
super (urls);
}
public void addFile (String path) throws MalformedURLException
{
String urlPath = "jar:file://" + path + "!/";
addURL (new URL (urlPath));
}
}
Now swap bundleclassloader with your classloader !
ClassLoader currentLoader = Thread.currentThread().getContextClassLoader();
try {
current.setContextClassLoader( newLoader);
// Either Load reqd. classes and work with them
newLoader.loadClass ("org.jruby.JRubyClient");
newLoader.loadClass ("org.hsqldb.jdbcDriver");
newLoader.loadClass("oracle.jdbc.driver.OracleDriver");
// Or invoke some other api (of scriptRunner.jar which will load JRuby classes to compile/run jruby script)
}catch(Exception exception) {
exception.printStackTrace();
}finally { // Restore Eclipse Bundle Class-loader
current.setContextClassLoader(oldLoader);
}
further reading : http://www.eclipsezone.com/articles/eclipse-vms/
No comments:
Post a Comment