Dissect Eclipse Plugin Framework

在讨论Xerdoc DSearch的架构的时候，我们就讨论决定采用Eclipse Plugin Framework，可惜那时Eclipse Plugin Framework和SWT以及其它耦合比较大，因此，决定借鉴Eclipse Plugin Framework的思想，来实现一个自己的轻量级的Plugin Framework。

一晃已经过去快一年了，其实非常早就想把自己研究Eclipse Plugin Framework的心得写下来，米嘉也一再催促，不过一直比较懒，觉着这个题目实在要写的太多，于是一直拖着。后来想想，真的应该早点儿把自己的一些粗糙想法写出来，即是对自己的一个总结，也能对其他人有些帮助。

Eclipse Plugin Framework是一套非常成功的插件框架结构，它的架构师之一就是鼎鼎大名的Erich Gamma，设计模式的作者之一。Eclipse JDT就是架构在这个插件平台上的一个杰出的Java IDE。Eclipse 良好的插件架构也形成了很好的"An architecture of participation"，你可以在Eclipse的社区中找到各种各样的插件，这些插件又极大的扩充了Eclipse的功能，提高了易用性。

记着候捷在写《深入浅出MFC》的时候，用很简单甚至粗糙的一些例子来模仿MFC内部的行为（比如消息循环等），效果非常好。我也想用一些Xerdoc DSearch中的代码来模仿一下Eclipse的插件架构。

注：这里所指的Eclipse Plugin Framework的Codebase是2.1.3，因为当时研究的时候，3.0（OSGi Based）还没出来 。

1) 插件清单

Eclipse中的插件都用XML文件来进行描述，比如：

1. <?xml version="1.0" encoding="utf-8"?>
2. <plugin id="org.eclipse.pde.source" name="%pluginName" version="2.1.3" provider-name="%providerName"> 
3.     <runtime></runtime>
4.     <extension point="org.eclipse.pde.core.source">
5.         <location path="src"> </location>
6.     </extension> 
7. </plugin>

这个清单中描述了插件的绝大多数信息，包括插件的id, name(这个是经过i18n的)，版本，启动类等。同时，所有的扩展、扩展点也都在这里定义，此插件对外提供的库（包括Native库）以及资源也都要定义在这个文件中。

这个文件的名称是"plugin.xml"，Eclipse启动的时候会扫描"plugins"目录下的所有"plugin.xml"文件，进而装载所有的插件。（注：为了提高效率，Eclipse会保存一个中间文件来加速装载，这里并不讨论。）

因此，你需要用XML Parser将这些信息Parse出来，形成插件的基本信息，具体选用Dom、SAX还是Pull Parser都无所谓。

Eclipse采用微内核＋插件的模式构架，也就是说，除了一个微小的核儿之外，所有的东西都是插件(All are plugins)。

2) 扩展点概述

Eclipse Plugin Framework最核心的概念应该就要算"Extension Point"（扩展点）了。

打个通俗的比方，"Extension Point"就像我们日常生活中的插销板，而"Extension"就是能够插入到这个插销板上面的插销。

系统的开放性很大程度上也取决于系统究竟给你多少"Extension Point"。

WordPress的Plugin Framework也同样采用这种"Extension Point"的概念构架，它为自己几乎所有的应用都定义了扩展点。比如，有的插件可以在"Header显示扩展点"的地方加入代码来添加CSS样式表，Google Sitemap插件可以在"文章发布扩展点"的地方进行Google Sitemap的提交，Creative Commons插件可以在"Footer显示扩展点"处增加"Creative Common"信息等等。

对于Eclipse来说，因为采用微内核＋插件的方式，因此，定义扩展点也就成了你的任务，在扩展功能的同时，你也可以在任何你觉得可能被扩展的地方定义扩展点，来方便其他人扩展系统的功能。

举个例子，Eclipse SWT UI中，工具栏、视图都留有扩展点，这样可以方便的进行扩展。

Eclipse的插件扩展点都定义在"plugin.xml"文件中，每个插件要扩展哪些扩展点也定义在这个文件中。举个例子（DS中Core插件的一个片断）：

1. <extension-point id="Parser"> 
2.     <parameter-def id="class" type="string"/> 
3.     <parameter-def id="icon" type="string"/>
4. </extension-point>

这并不是Eclipse Plugin的DTD所规范的"plugin.xml"格式，而是一个非常简单的模拟。它描述的是一个"Parser"的扩展点。因此，你可以扩展任何自己的Parser（比如QQ聊天记录的Parser，Foxmail Mail的Parser，等等），增加Desktop Search可处理文件的范围。

3) ClassLoader

了解Eclipse的Plugin Framework需要对ClassLoader（类装载器）有比较深入的了解，建议读读JDK的源代码，会很有帮助。

ClassLoader - 顾名思义，就是Java中用来装载类的部分，要将一个类的名字装载为JVM中实际的二进制类数据。在JVM中，任何一个类被加载，都是通过ClassLoader来实现的，同时，每个Class对象也都有一个引用指向装载他的ClassLoader,你可以通过getClassLoader()方法得到它。

ClassLoader只是一个抽象类，你可以定义自己的ClassLoader来实现特定的Load的功能。Eclipse Plugin Framework就实现了自己的ClassLoader。

ClassLoader使用所谓的"Delegation Model"（“双亲委托模型”）来查找、定位类资源。每一个ClassLoader都有自己一个父ClassLoader实例（在构造的时候传入），当这个ClassLoader被要求加载一个类时，它首先会询问自己的父ClassLoader，看看他是否能加载（注意：这个过程是一直递归向上的），如果不能的话，才自己加载。

Java ClassLoader的体系结构是

最后来看一下代码：

1. protected synchronized Class<?> loadClass(String name, boolean resolve)
2.     throws ClassNotFoundException
3.     {
4.     // First, check if the class has already been loaded
5.     Class c = findLoadedClass(name);
6.     if (c == null) {
7.         try {
8.         if (parent != null) {
9.             c = parent.loadClass(name, false);
10.         } else {
11.             c = findBootstrapClass0(name);
12.         }
13.         } catch (ClassNotFoundException e) {
14.             // If still not found, then invoke findClass in order
15.             // to find the class.
16.             c = findClass(name);
17.         }
18.     }
19.     if (resolve) {
20.         resolveClass(c);
21.     }
22.     return c;
23. }

可见，ClassLoader首先会查找该类是否已经被装载，如果没有，就询问自己的父ClassLoader，如果还不能装载，就调用findClass()方法来装载类。所以，一般简单的自定义ClassLoader只需要重写findClass方法就可以了。

如果你的类不是文件，比如说是序列化在数据库中的二进制流或者网络上的Bit流，就需要重写defineClass()方法，来将二进制数据映射到运行时的数据结构。另外一种需求也可能是你需要对类文件进行某种操作（比如按位取反？），也需要定义自己的defineClass()方法。

还需要注意的是资源的加载和系统Native库的加载，这个可以留在以后再作讨论。

4) Plugin与PluginClassLoader

准备工作做完，就可以来看看具体实现过程。

我们模拟的几个重要的类是：

Plugin: 插件类，描述每个具体插件；

PluginDescriptor: 插件描述符，记录了插件的ID、Name、Version、依赖、扩展点等；

PluginManager: 插件管理器，负责所有插件资源的管理，包括插件的启动、停止、使能（Enable/Disable）等等；

PluginRegistry: 插件注册表，提供了一个由插件ID到Plugin的映射；

我们首先来定义一个简单的Plugin：

1. public abstract class Plugin {
2.     /**
3.      * Plugin State
4.      */
5.     private boolean started_;
7.     private final PluginManager manager_;
9.     private final IPluginDescriptor descriptor_;
11.     public Plugin(PluginManager manager, IPluginDescriptor descr) {
12.         manager_ = manager;
13.         descriptor_ = descr;
14.     }
16.     /**
17.      * @return descriptor of this plug-in
18.      */
19.     public final IPluginDescriptor getDescriptor() {
20.         return descriptor_;
21.     }
23.     /**
24.      * @return manager which controls this plug-in
25.      */
26.     public final PluginManager getManager() {
27.         return manager_;
28.     }
30.     final void start() throws PluginException {
31.         if (!started_) {
32.             doStart();
33.             started_ = true;
34.         }
35.     }
37.     final void stop() throws PluginException {
38.         if (started_) {
39.             doStop();
40.             started_ = false;
41.         }
42.     }
44.     public final boolean isActive() {
45.         return started_;
46.     }
48.     /**
49.      * Get the resource string
50.      * @param key
51.      * @return
52.      */
53.     public String getResourceString(String key) {
54.         IPluginDescriptor desc = getDescriptor();
55.         return desc.getResourceString(key);
56.     }
58.     /**
59.      * Get the Plugin Path
60.      *
61.      * @return
62.      */
63.     public String getPluginPath() {
64.         return getDescriptor().getPluginHome();
65.     }
67.     /**
68.      * Template method, which will do the really start work
69.      *
70.      * @throws Exception
71.      */
72.     protected abstract void doStart() throws PluginException;
74.     /**
75.      * Template method, which will do the really stop work
76.      *
77.      * @throws Exception
78.      */
79.     protected abstract void doStop() throws PluginException;
80. }

可见，这只是一个抽象类，每个插件需要定义自己的派生自"Plugin"的子类，作为本插件的一个入口。其中doStart和doStop是两个简单的模板方法，每个插件的初始化和资源释放操作可以定义在这里。

接下来我们看看系统的启动流程：首先将所有的插件清单读入（"plugin.xml"），并根据这个文件解析出PluginDescriptor（包括这个Plugin的所有导出库、依赖插件、扩展点等等），放到PluginRegistry中。这个过程也是整个插件平台的一个非常重要的部分，需要从插件清单中解析的部分包括：

1. 每个插件所依赖的的插件列表（在"plugin.xml"中用"require" element标识）；
2. 每个插件要输出的资源和类（在"plugin.xml"中用"library" element标识）；
3. 每个插件所声明的扩展点列表；
4. 每个插件所声明的扩展列表（扩展其它扩展点的扩展）。

当把所有的插件信息都读入到系统中，就可以根据自己的需要来启动指定的插件了（比如，在Xerdoc DS中，首先，我们会启动Core插件）。

启动一个插件的步骤是：

1. public Plugin getPlugin(String id) throws PluginException {
2.     ... ...
4.     IPluginDescriptor descr = pluginRegistry_.getPluginDescriptor(id);
5.     if (descr == null) {
6.         throw new PluginException("Cannot found this plugin " + id);
7.     }
9.     result = activatePlugin(descr);
11.     return result;
12. }
14. private synchronized Plugin activatePlugin(IPluginDescriptor descr)
15.         throws PluginException {
16.     ... ...
17.    
18.     try {
19.         try {
20.             // 首先需要检查这个插件所依赖的插件是否都已经启动，
21.             // 如果没有，则需要先启动那些插件，才能启动本插件
22.             checkPrerequisites(descr);
23.         } catch (PluginException e) {
24.             badPlugins_.add(descr.getId());
25.             throw e;
26.         }
28.         //    得到插件的主类名
29.         //    这个信息也是定义在"Plugin.xml"中，
30.         //    并且在加载插件信息的时候读入到PluginDescriptor中的
31.        
32.         String className = descr.getPluginClassName();
33.         if ((className == null) || "".equals(className.trim())) {
34.             result = null;
35.         } else {
36.             Class pluginClass;
37.             try {
38.            
39.                 //    用每个插件自己的PluginClassLoader来得到这个插件的主类
40.                
41.                 pluginClass = descr.getPluginClassLoader().loadClass(
42.                         className);
43.             } catch (ClassNotFoundException cnfe) {
44.                 badPlugins_.add(descr.getId());
45.                 throw new PluginException("can't find plug-in class "
46.                         + className);
47.             }
48.             try {
49.                 Class pluginManagerClass = getClass();
50.                 Class pluginDescriptorClass = IPluginDescriptor.class;
52.                 Constructor constructor = pluginClass
53.                         .getConstructor(new Class[] { pluginManagerClass,
54.                                 pluginDescriptorClass });
56.                 //    调用插件默认的构造函数
57.                 //    Plugin(PluginManager, IPluginDescriptor);
58.                
59.                 result = (Plugin) constructor.newInstance(new Object[] {
60.                         this, descr });
61.             } catch (InvocationTargetException ite) {
62.                 ... ...
63.             } catch (Exception e) {
64.                 ... ...
65.             }
67.             try {
68.                 result.start();
69.             } catch (Exception e) {
70.                 ... ...
71.             }
73.             ... ...
74.         }
75.     }
77.     return result;
78. }

其实最核心的工作就是三步：

1. 首先检查这个插件所依赖的其它插件是否已经被启动，如果没有，则需要首先将那些插件启动；
2. 根据类名，用插件类加载器加载这个类（这个类是Plugin类的一个派生类）；
3. 调用Plugin类的默认的构造函数（主要是为了将PluginManager和PluginDescriptor传进去）。

这就用到了前面说过的类加载器（ClassLoader），Eclipse中定义了插件类加载器（PluginClassLoader）。插件类加载器（PluginClassLoader）其实很简单，它派生自URLClassLoader -

This class loader is used to load classes and resources from a search path of URLs referring to both JAR files and directories.

PluginClassLoader会将PluginDescriptor中声明输出的路径（可以是JAR文件，可以是类路径，可以是资源路径）加入到此URLClassLoader类加载器的搜索路径中去。

比如：

1. <runtime>
2.     <library id="com.xerdoc.desktop.view.htmlrender" path="XerdocDSHTMLRender.jar" type="code">
3.         <export prefix="*"/>
4.     </library>   
5.     <library id="resources" path="image/" type="resources">
6.         <export prefix="*"/>                   
7.     </library>           
8. </runtime>

PluginClassLoader会将"XerdocDSHTMLRender.jar"和"image/"目录都加入到URLClassLoader的类搜索路径中去，这样，就可以用这个类加载器来加载相应的插件类和资源了。

PluginClassLoader加载插件的策略是：

首先试图从父ClassLoader加载（系统类加载器），如果无法加载则会试图从本类加载器加载，如果还是找不到，这时的行为与一般的URLClassLoader不同，也PluginClassLoader最大的特色：它会试图从此插件的需求依赖插件（"require"形容的插件）中去加载需求的类或者资源。

比如下面这个例子：

1. <requires>
2.     <import plugin-id="com.xerdoc.desktop.core" plugin-version="0.4.0" match="compatible"/>
3.     <import </