woaidongmao

文章均收录自他人博客,但不喜标题前加-[转贴],因其丑陋,见谅!~
随笔 - 1469, 文章 - 0, 评论 - 661, 引用 - 0
数据加载中……

Dissect Eclipse Plugin Framework

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

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

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

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

注:这里所指的Eclipse Plugin FrameworkCodebase2.1.3,因为当时研究的时候,3.0OSGi Based)还没出来 clip_image001

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出来,形成插件的基本信息,具体选用DomSAX还是Pull Parser都无所谓。

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

2) 扩展点概述

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

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

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

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

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

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

Eclipse的插件扩展点都定义在"plugin.xml"文件中,每个插件要扩展哪些扩展点也定义在这个文件中。举个例子(DSCore插件的一个片断):

1.           <extension-point id="Parser"> 

2.               <parameter-def id="class" type="string"/> 

3.               <parameter-def id="icon" type="string"/>

4.           </extension-point>

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

3) ClassLoader

了解EclipsePlugin 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的体系结构是

clip_image002

最后来看一下代码:

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

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

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

Plugin: 插件类,描述每个具体插件;

PluginDescriptor: 插件描述符,记录了插件的IDNameVersion、依赖、扩展点等;

PluginManager: 插件管理器,负责所有插件资源的管理,包括插件的启动、停止、使能(Enable/Disable)等等;

PluginRegistry: 插件注册表,提供了一个由插件IDPlugin的映射;

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

1.           public abstract class Plugin {

2.               /**

3.                * Plugin State

4.                */

5.               private boolean started_;

6.            

7.               private final PluginManager manager_;

8.            

9.               private final IPluginDescriptor descriptor_;

10.        

11.           public Plugin(PluginManager manager, IPluginDescriptor descr) {

12.               manager_ = manager;

13.               descriptor_ = descr;

14.           }

15.        

16.           /**

17.            * @return descriptor of this plug-in

18.            */

19.           public final IPluginDescriptor getDescriptor() {

20.               return descriptor_;

21.           }

22.        

23.           /**

24.            * @return manager which controls this plug-in

25.            */

26.           public final PluginManager getManager() {

27.               return manager_;

28.           }

29.        

30.           final void start() throws PluginException {

31.               if (!started_) {

32.                   doStart();

33.                   started_ = true;

34.               }

35.           }

36.        

37.           final void stop() throws PluginException {

38.               if (started_) {

39.                   doStop();

40.                   started_ = false;

41.               }

42.           }

43.        

44.           public final boolean isActive() {

45.               return started_;

46.           }

47.        

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.           }

57.        

58.           /**

59.            * Get the Plugin Path

60.            *

61.            * @return

62.            */

63.           public String getPluginPath() {

64.               return getDescriptor().getPluginHome();

65.           }

66.        

67.           /**

68.            * Template method, which will do the really start work

69.            *

70.            * @throws Exception

71.            */

72.           protected abstract void doStart() throws PluginException;

73.        

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"的子类,作为本插件的一个入口。其中doStartdoStop是两个简单的模板方法,每个插件的初始化和资源释放操作可以定义在这里。

接下来我们看看系统的启动流程:首先将所有的插件清单读入("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.               ... ...

3.            

4.               IPluginDescriptor descr = pluginRegistry_.getPluginDescriptor(id);

5.               if (descr == null) {

6.                   throw new PluginException("Cannot found this plugin " + id);

7.               }

8.            

9.               result = activatePlugin(descr);

10.        

11.           return result;

12.       }

13.        

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.               }

27.        

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;

51.        

52.                       Constructor constructor = pluginClass

53.                               .getConstructor(new Class[] { pluginManagerClass,

54.                                       pluginDescriptorClass });

55.        

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.                   }

66.        

67.                   try {

68.                       result.start();

69.                   } catch (Exception e) {

70.                       ... ...

71.                   }

72.        

73.                   ... ...

74.               }

75.           }

76.        

77.           return result;

78.       }

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

1.           首先检查这个插件所依赖的其它插件是否已经被启动,如果没有,则需要首先将那些插件启动;

2.           根据类名,用插件类加载器加载这个类(这个类是Plugin类的一个派生类);

3.           调用Plugin类的默认的构造函数(主要是为了将PluginManagerPluginDescriptor传进去)。

这就用到了前面说过的类加载器(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 plugin-id="com.xerdoc.desktop.core.ui.swt" plugin-version="0.2.0" match="compatible"/>

4.           </requires>

这是Office Excel Parser插件清单的片断。如果这个插件的类加载器无法加载某个需要的类或者资源,将会委托"com.xerdoc.desktop.core"插件或者"com.xerdoc.desktop.core.ui.swt"插件的类加载器去加载。

系统Native Library(比如SWT插件中要用到的系统本地库)的加载也是PluginClassLoader的功能。

就举SWT的例子,熟悉SWT的人都知道,运行SWT应用程序的时候需要添加以下命令行参数:

-Djava.library.path="/home/elan/workspace/xerdoc_ds/swt-native"

这就是为了让类加载器能够在相应的目录("/home/elan/workspace/xerdoc_ds/swt-native")下面找到需要的系统本地库资源。但是这样的命令行参数对于某些应用并不合适。对于Xerdoc DS来说,SWTUI界面也同样是一个插件,同时也还会有其它用到本地资源库的插件,总不能增加一个插件还要修改命令行参数吧?因此,需要修改ClassLoader,使之能够加载指定的Native Library。方法就是重写findLibrary函数:

1.           /**

2.           * Returns the absolute path name of a native library.  The VM invokes this

3.           * method to locate the native libraries that belong to classes loaded with

4.           * this class loader. If this method returns <tt>null</tt>, the VM

5.           * searches the library along the path specified as the

6.           * "<tt>java.library.path</tt>" property.  </p>

7.           *

8.           * @param libname

9.           *         The library name

10.       *

11.       * @return The absolute path of the native library

12.       *

13.       * @see System#loadLibrary(String)

14.       * @see System#mapLibraryName(String)

15.       *

16.       * @since 1.2

17.       */

18.       protected String findLibrary(String libname) {

19.           return null;

20.       }

重写其实很简单,只需要根据每个插件需要加载Native Library的目录来搜索就可以了,比如这是Linux下面,SWT插件清单的片断:

1.           <library id="swt-native" path="swt-native/" type="native_library">

2.               <export prefix="*"/>                   

3.           </library>

这样,在找Native Library的时候就可以从"$PLUGIN_HOME/swt-native/"这个目录中找到相应的so文件(Linux下的动态链接库)。

最后来说说资源文件(比如说png, ico等等),其实同加载类资源一样,只要在"library"中声明的目录,就都会加入到类加载器的类搜索路径中去,这样,我们都可以直接访问里面的资源。

5) I18N

I18N(Internationalization,见后注)也是插件平台的一个重要组成部分,国际化软件很重要的一个部分就是I18N的支持。这其实也是"An architecture of participation"的一个方面,只要你留出良好的接口,别人会替你进行各种语言的Translation工作。

Java对于I18N有非常好的支持,可以看看SunOnline Tutorial,其实最重要的概念就算是LocaleResourceBundle了。

先来看看Locale

A Locale object represents a specific geographical, political, or cultural region

常见的比如"zh_CN", "en_US"等等 。它是由Language(语言)和Country(国家/地区)两部分组成的,比如"en"表示英语,"US"表示美国,通常,我们可以通过Locale.getDefault()来得到本地默认的Locale

当你将Locale设置为其它,理论上,系统的语言、习惯等等也应该被相应的切换。

再来看看ResourceBundle

Resource bundles contain locale-specific objects. When your program needs a locale-specific resource, a String for example, your program can load it from the resource bundle that is appropriate for the current user’s locale. In this way, you can write program code that is largely independent of the user’s locale isolating most, if not all, of the locale-specific information in resource bundles.

ResourceBundle实例化的策略为:

1) 名字

简单的说,首先会根据你设定的LocaleBase Name来取得相应的名字,比如默认的来说,我们的中文系统中,Base Name = "plugin"的情况下,搜索的顺序为:

plugin_zh_CN

plugin_zh

plugin

所以,Xerdoc DS默认都会提供中、英两种Resource文件("plugin_zh_CN.properties", "plugin.properties"),当然,也可以很方便的根据"plugin.properties"翻译成为其它语言(比如法语、德语)。

这样的结果是,如果你设置为中文Locale,那么则读取"plugin_zh_CN.properties",如果设置为英文,则读取"plugin.properties",如果设置为德文等其它找不到的,也默认的使用英文的"plugin.properties"

2)类 or Properties文件 ?

ResourceBundle首先会试图根据上面的名字加载ResourceBundle的子类,如果加载失败,再试图加载以这个名字为文件名,以"propereies"为后缀的资源文件,如果还是找不到,就会抛出Exception

根据这样两步,ResourceBundle完成自己的实例化。

这样,可以为每个插件都配一个自己的ResourceBundle,负责自己插件的I18N工作。

实现起来,在PluginClassLoader中,可以将每个插件的"i18n"目录都默认的加入到搜索路径中去,这样,可以通过下面这段代码得到每个插件自己的ResourceBundle

1.           ...

2.            

3.           private static final String RESOURCE_BUNDLE_NAME = "plugin";

4.            

5.           ...

6.            

7.           /**

8.           * I18N Work

9.           */

10.        

11.       /**

12.       * Returns the plugin's resource bundle,

13.       */

14.       public ResourceBundle getResourceBundle() {

15.           try {

16.               if (resourceBundle_ == null) {

17.                   ClassLoader loader = getPluginClassLoader();

18.                   resourceBundle_ = ResourceBundle.getBundle(

19.                           RESOURCE_BUNDLE_NAME, Locale.getDefault(), loader);

20.               }

21.           } catch (MissingResourceException x) {

22.               resourceBundle_ = null;

23.           }

24.           return resourceBundle_;

25.       }

得到ResourceBundle后,就可以通过它来得到所需要的字符串什么的了:

1.           resourceBundle_.getString("parser.word.title");

有两个注意的是:

1.           编译的时候,编码应该指定为utf-8

2.           程序中所有的字符串应该都由ResourceBundle得到,不应该出现硬编码。

写到这里,想起原来用Visual C++开发项目。I18N的道理其实差不多,不过是将字符串都写到RC文件中(二进制)。相比起来,VCI18N的支持比Java还是要差不少。

最后补充一点的是,Eclipse插件清单("plugin.xml")中需要I18N的字符串通常在前面添加"%",这样在取得这样的字符串后,ResourceBundle可以根据这个Keyproperties中取出相应的I18N后的字符串,并表示出来。

注:I18N作为Internationalization的简称,表示中间省略18个字母,常用的还有G10N(Globalization), A11Y(Accessbility)等等。

6) Lazy Loading

在介绍"Extension Point"之前,先来看一个概念:Eclipse中著名的懒加载原则(Lazy Loading Rule)。

懒加载法则:只有在真正需要的时候才加载插件,实现起来最重要的方面就是声明和实现的分离。

插件的外形(比如名字,ID,图标)等等都在插件描述清单"plugin.xml"中声明,而具体功能封装在class文件中。

这种懒加载原则表现在各个方面,比如最基本的插件启动。系统在启动的时候,只加载和启动最必须的一些插件,而其它插件只有在真正用到的时候才被加载和启动,这样可以最大限度的节省系统启动时的资源和时间。而对用户来说,每次启动也确实有很多插件根本不会去用到。

懒加载还表现在扩展点的应用上,待会儿可以看到具体例子。

7) 扩展点的实现

接下来就看看"Extension Point",像前面曾经介绍的那样,"Extension Point"Eclipse Plugin Frame中最核心的概念。首先来看一个Xerdoc DS"Extension Point""Extension"的声明:

1.           <extension-point id="Parser">

2.               <parameter-def id="class" type="string"/>       

3.               <parameter-def id="icon" type="string"/>

4.           </extension-point>

这是"core"插件中关于"Parser"的扩展点,你可以定义不同的扩展,来增强Xerdoc DS能够索引文件类型的范围。

1.           <extension plugin-id="com.xerdoc.desktop.core" point-id="Parser" id="MP3FileParser">

2.               <parameter id="class" value="com.xerdoc.desktop.parser.mp3.MP3FileParser"/>

3.               <parameter id="icon" value="image/mime_icon_Music_mp3.gif"/>

4.           </extension>

这是"mp3 parser"插件中对此扩展点的一个扩展声明,声明了自己扩展的类和图标。图标完全是为了显示,而其中的"class"则是为了加载真正的功能。

"core"插件会在需要的时候加载所有扩展了这个扩展点的插件:

1.           private static void loadSupportedParsers() {

2.               ... ...

3.              

4.               try {

5.                   descriptor = manager.getPlugin("com.xerdoc.desktop.core")

6.                           .getDescriptor();

7.            

8.                   //    得到Parser扩展点声明

9.                   IExtensionPoint extPoint = descriptor.getRegistry()

10.                       .getExtensionPoint(descriptor.getId(), "Parser");

11.        

12.               //    根据这个声明得到所有连接到这个扩展点的扩展对象

13.               for (Iterator it = extPoint.getConnectedExtensions().iterator(); it

14.                       .hasNext();) {

15.                   IExtension ext = (IExtension) it.next();

16.                  

17.                   //    根据扩展对象生成Parser代理

18.                   //    也就是著名的懒加载法则

19.                   ParserProxy parser = ParserProxy.createParserProxy(ext);

20.        

21.                   parserList_.add(parser);

22.               }

23.           } catch (PluginException e) {

24.               e.printStackTrace();

25.           }

26.       }

ParserProxy其实就是Parser的代理,它只读取Parser的表现部分,比如图标,名称等等,而实例化的操作要等到具体使用的时候才去调用。

1.           ...

2.            

3.           /**

4.           * Parser Extension Point

5.           */

6.           private IExtension extension_;

7.            

8.           /**

9.           * Real Parser Instance, it will not be load until really needed

10.       */

11.       private AbstractParser realParser_;

12.        

13.       ...

14.          

15.       private ParserProxy(IExtension extension) {

16.           extension_ = extension;

17.       }

18.        

19.       /**

20.       * Create the Parser Proxy based on the Extension

21.       *

22.       * @param extension

23.       * @return

24.       */

25.       public static ParserProxy createParserProxy(IExtension extension) {

26.           return new ParserProxy(extension);

27.       }

当真正需要这个Parser的时候,ParserProxy会生成相应的真实对象(如其名,这是Proxy模式的典型应用):

1.           private AbstractParser getRealInstance() {

2.               if (realParser_ == null) {

3.                   try {

4.                       //    得到插件

5.                       //    如果插件还未被激活,这里要激活这个插件

6.                       //    LAZY LOADING!!!

7.                      

8.                       Plugin plugin = CorePlugin.getInstance().getManager()

9.                               .getPlugin(

10.                                   extension_.getDeclaringPluginDescriptor()

11.                                           .getId());

12.        

13.                   if (plugin != null) {

14.                       Class pluginCls = plugin.getClass();

15.                      

16.                       //    得到主类

17.                       Class cls = extension_.getDeclaringPluginDescriptor()

18.                               .getPluginClassLoader().loadClass(

19.                                       extension_.getParameter("class")

20.                                               .valueAsString());

21.        

22.                       if (cls != null) {

23.                           if (pluginCls.isAssignableFrom(cls)) {

24.                               realParser_ = (AbstractParser) plugin;

25.                           } else {

26.                               //    反射生成这个类

27.                               realParser_ = (AbstractParser) cls.newInstance();

28.                           }

29.                       }

30.                   }

31.               } catch (Exception e) {

32.                   return null;

33.               }

34.           }

35.        

36.           return realParser_;

37.       }

然后,就可以调用这个Parser完成必要的工作了。这就是"Extension Point"的大概的工作流程。

Eclipse中,遍地都是这样的例子,比如:Eclipse Platform的菜单显示就是一个扩展点,Eclipse在显示菜单之前首先会从系统的插件列表(PluginRegistry)中寻找所有扩展此扩展点的插件,取得图标和名字显示出来,然后在用户点击的时候生成真实的对象,并调用之,嗯,还是懒加载法则。

BTW:菜单扩展中的类是IAction,点击的时候调用它的run()函数,Command模式。

写这些的时候想起来,在声明每个扩展点前,这个插件都需要定义一定的Interface,也就是扩展这个扩展点的插件需要遵循的API。这个Interface如果用C#中的Delegate实现,是不是会看起来更好呢?(从包的import等等)。不知道有没有C#模仿Eclipse Plugin Framework的实例。

8) 写在后面

对于一个良好的插件平台来说,仅有一个良好的插件架构是不够的,还需要有非常方便易用的插件开发环境。EclipsePDE就是这样的产品,它能够很大程度帮助程序员开发插件,极大降低其它人participation的难度 clip_image003

相比之下,Netbeans就没有这样的插件开发环境(Netbeans中,插件都叫做模块 - "Module"),因此,开发插件还是一件很麻烦的事情,这也就造成了其他人participation的困难。

基本上就是这样,Eclipse2.1的插件结构真的非常优秀,看到那些代码的时候更佩服最初设计者的想法。Eclipse2.1 Plugin Framework也有一些缺点,比如不能Load/Unload on the fly(动态加载/卸载),需要重启Eclipse等等。

Eclipse3.0之后,Eclipse决定遵循OSGi的标准来重构其插件机制,拥抱标准,总是一件美好的事情。

最后强烈推荐 "Contributing to Eclipse",由Erich GammaKent Beck执笔,值得一读。

More entries about : Eclipse, Plugin Framework

原文地址: http://www.mengyan.org/blog/tag/Framework

posted on 2009-09-02 21:30 肥仔 阅读(1443) 评论(1)  编辑 收藏 引用 所属分类: 编程思想

评论

# re: Dissect Eclipse Plugin Framework  回复  更多评论   

不错支持下,再分享35本编程入门教程(ITPUX技术网的编程书籍下载地址:http://www.itpux.com/article-17-1.html ),推荐的包括HTML/CSS/JavaScript/HTML5/jQuery/PHP/ASP/Python/Android/iOS/C/LINUX等编程自学入门书籍。
2015-03-08 11:39 | IT技术网站

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理