一种插件管理方法及装置与流程

本申请涉及互联网应用技术领域，特别涉及一种插件管理方法及装置。

背景技术：

在互联网时代，web应用因其具有高度的使用便捷性及良好的跨平台特性而占据着计算机应用的大部分市场。用户只需要在智能终端的浏览器输入网址，即可访问并使用web应用。对于web应用开发人员来说，对于web应用的维护异常方便，只需要维护一套程序即可，不必考虑应用软件对操作系统的要求。当web应用需要升级时，只需要更新web应用的服务器端程序即可，不必每台客户端都进行更新升级操作。

在传统互联网技术中，对于web应用的升级，基本上都需要关闭web应用的服务器，再更新web服务器中的代码，升级服务器端的配置文件，然后重启web服务器，提供更完善的web应用服务。这一web应用升级过程需要web服务器先后经历关闭、更新及重启的过程，其升级过程繁琐。为了简化升级过程，发明人提出web系统插件机制，web系统插件机制具体为：将web系统进行功能上的划分，得到多个功能模块，每一个功能模块作为一个单独的插件进行开发，最后将开发完成的各个单独的插件组合在一起，得到完整的web系统，且每个插件均支持热插拔。从而实现可以在线升级一个或多个插件，避免web服务器先后经历关闭、更新及重启的过程。

但是，在新的web系统插件机制中，如何对单个插件进行管理成为问题。

技术实现要素：

为解决上述技术问题，本申请实施例提供一种插件管理方法及装置，以达到实现对单个插件的管理的目的，技术方案如下：

一种插件管理方法，包括：

对插件的状态进行管理；

对所述插件的排序进行管理。

优选的，对插件的状态进行管理，包括：

获取所述插件所属web系统的运行状态和所述插件的加载状态；

若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为加载完成状态，则确定所述插件的状态为运行状态，并将表征运行状态的插件状态信息保存在插件状态信息记录文件中；

若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为未被加载状态，则确定所述插件的状态为停止状态，并将表征停止状态的插件状态信息保存在所述插件状态信息记录文件中；

在确定所述插件的状态为停止状态后，判断所述插件是否被删除；

若所述插件被删除，确定所述插件的状态为卸载状态，并删除所述插件状态信息记录文件中关于所述插件的插件状态信息。

优选的，对所述插件的排序进行管理，包括：

为所述插件分配排序号，并将分配得到的排序号保存在插件排序信息记录文件中；

对所述插件排序信息记录文件中的所述插件的排序号进行修改。

优选的，所述方法还包括：

将所述插件的状态修改为停止状态，并获取新版本的插件；

利用所述新版本的插件更新所述插件。

优选的，所述方法还包括：

若所述插件的状态为运行状态，则停止运行所述插件，并将所述插件的状态修改为停止状态；

卸载所述插件。

一种插件管理装置，包括：

第一管理模块，用于对插件的状态进行管理；

第二管理模块，用于对所述插件的排序进行管理。

优选的，所述第一管理模块包括：

获取单元，用于获取所述插件所属web系统的运行状态和所述插件的加载状态；

第一确定单元，用于若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为加载完成状态，则确定所述插件的状态为运行状态；

第一保存单元，用于将表征运行状态的插件状态信息保存在插件状态信息记录文件中；

第二确定单元，用于若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为未被加载状态，则确定所述插件的状态为停止状态；

第二保存单元，用于将表征停止状态的插件状态信息保存在所述插件状态信息记录文件中；

判断单元，用于在确定所述插件的状态为停止状态后，判断所述插件是否被删除，若所述插件被删除，则执行删除单元；

所述删除单元，用于确定所述插件的状态为卸载状态，并删除所述插件状态信息记录文件中关于所述插件的插件状态信息。

优选的，所述第二管理模块包括：

分配单元，用于为所述插件分配排序号；

第三保存单元，用于将分配得到的排序号保存在插件排序信息记录文件中；

修改单元，用于对所述插件排序信息记录文件中的所述插件的排序号进行修改。

优选的，所述装置还包括：

获取模块，用于将所述插件的状态修改为停止状态，并获取新版本的插件；

更新模块，用于利用所述新版本的插件更新所述插件。

优选的，所述装置还包括：

停止模块，用于若所述插件的状态为运行状态，则停止运行所述插件，并将所述插件的状态修改为停止状态；

卸载模块，用于卸载所述插件。

与现有技术相比，本申请的有益效果为：

在本申请中，通过对插件的状态进行管理，以及对插件的排序进行管理，实现对单个插件的管理。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的插件管理方法的一种流程图；

图2是本申请提供的插件管理方法的一种子流程图；

图3是本申请提供的插件管理方法的另一种子流程图；

图4是本申请提供的插件管理方法的另一种流程图；

图5是本申请提供的插件管理方法的再一种流程图；

图6是本申请提供的插件管理装置的一种逻辑结构示意图；

图7是本申请提供的插件管理装置的另一种逻辑结构示意图；

图8是本申请提供的插件管理装置的再一种逻辑结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例一

在本实施例中，在新的web插件机制中，将web系统进行功能上的划分，得到多个功能模块，每一个功能模块作为一个单独的插件进行开发。插件即一个子功能模块。插件的实体是一个zip的压缩文件，运行时系统会将该压缩文件进行解压，产生一个文件夹。

插件的主要目录结构分为三个部分，分别为：插件基本信息目录、插件后端资源目录和插件前端资源目录。

其中，插件基本信息目录如下：

插件基本信息目录为META-INF目录。该目录下只包含一个MANIFEST.MF文件，该文件为插件基本信息的记录文件，也是该插件的标识文件(即一个zip或文件夹被识别为插件的唯一标识)。该文件中包含的基本信息有：Manifest-Version(Manifest版本信息)、Plugin-URI(插件统一资源标识符)、Plugin-Id(插件id)、Built-By(插件创建人)、Build-Jdk(插件编译环境版本)、Plugin-Version(插件版本号)、Created-By(插件构建工具)、Plugin-Package-Path(插件基本包路径)、Archiver-Version(插件归档插件版本)。

插件后端资源目录如下：

插件的后端资源目录为WEB-INF目录。该目录主要包括：

插件后端资源文件即java文件的编译文件(class文件)或java编译打包文件(jar文件)。以及后端资源文件所以依赖的其他后端资源文件。

插件配置文件：包括xml文件、properties文件、json文件等。

插件私有数据导出文件：sql文件、java对象序列化文件等。

插件前端资源目录如下：

除了上述目录外，其他的都是插件的前端资源文件。前端资源文件可能是多种多样的，包括：html文件、js文件、css文件、jsp文件、页面模板文件、图片资源文件、字体文件等等。

在本实施例中，插件的应用过程为：

1、系统启动时的插件加载：

(1)动态构建插件servlet：指定插件servlet的定义xml文件；根据定义xml文件构建插件servlet，并定义该servlet的名称；指定插件servlet初始化参数定义文件；将该插件servlet挂载到主servlet下。

(2)解压插件压缩包：由于插件分发文件是以zip压缩文件的形式保存和分发的，所以需要对插件进行解压缩操作，方便后续插件的使用。该部分主要工作是遍历插件目录(plugins)，对其中的zip插件文件，使用解压缩程序对其进行解压。

(3)记录插件基本信息，并保存到缓存中：遍历解压后的插件目录文件，获取其中的MANIFEST.MF文件；读取MANIFEST.MF文件中记录的插件基本信息；将读取到MANIFEST.MF文件中记录的插件基本信息保存当缓存中，以方便后期的使用；为了记录插件的状态，以及持久化插件状态信息，还需要将根据插件生成的状态信息保存在插件状态信息记录文件(plugins_info.properties)中，以备系统下次重新启动时获取之前的插件状态信息。其中状态信息包括(插件启动状态，插件停止状态)。

(4)扫描记录插件的资源文件：根据插件基本信息对插件进行扫描：对于启动状态的插件，记录下插件的资源文件路径；对于停止状态的插件，记录下插件的名称，保存到插件名称集合中；将记录的插件资源文件路径的信息保存到插件servlet中。

(5)为插件servlet添加映射：根据(3)中记录的插件基本信息，为启动状态的插件添加插件映射到插件servlet中；利用(4)中记录的停止状态插件名称集合，构建停止状态插件映射正则表达式，以阻止前端对已停止插件的访问。

(6)实例化插件servlet：根据(4)记录的插件资源，构建插件servlet的ClassLoader(类加载器)，并指定主servlet的ClassLoader为父ClassLoader；利用构建的插件servlet的ClassLoader，对(1)构建的插件servlet进行实例化

在本实施例中，插件的访问过程为：

定义插件的访问路径为：http://主机名/应用名/view/插件名/dirName1/dirName2...

插件所属web系统会对以/view开头的应用访问路径进行拦截，然后对路径信息进行解析，然后将请求转发到对应的插件服务进行处理。

在本实施例中，对插件进行管理的过程具体可以参见图1，其示出了本申请提供的插件管理方法的一种流程图，可以包括以下步骤：

步骤S11：对插件的状态进行管理。

步骤S12：对所述插件的排序进行管理。

在本申请中，通过对插件的状态进行管理，以及对插件的排序进行管理，实现对单个插件的管理。

在本实施例中，对插件的状态进行管理的过程可以参见图2，可以包括以下步骤：

步骤S21：获取所述插件所属web系统的运行状态和所述插件的加载状态。

步骤S22：若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为加载完成状态，则确定所述插件的状态为运行状态，并将表征运行状态的插件状态信息保存在插件状态信息记录文件中。

步骤S23：若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为未被加载状态，则确定所述插件的状态为停止状态，并将表征停止状态的插件状态信息保存在所述插件状态信息记录文件中。

步骤S24：在确定所述插件的状态为停止状态后，判断所述插件是否被删除。

若判断结果为是，则执行步骤S25。

运行状态的插件不能被删除，因为运行状态的插件资源仍然被占用，所以无法删除，因此首先需要停止运行插件，确定插件的状态为停止状态之后再进行插件的删除。

步骤S25：确定所述插件的状态为卸载状态，并删除所述插件状态信息记录文件中关于所述插件的插件状态信息。

在本实施例中，对所述插件的排序进行管理的过程可以参见图3，可以包括以下步骤：

步骤S31：为所述插件分配排序号，并将分配得到的排序号保存在插件排序信息记录文件中。

在本实施例中，插件排序信息记录文件可以和上述插件状态信息记录文件合并为一个文件，即排序号和插件状态信息可以记录在同一个文件中。当排序号和插件状态信息记录在同一个文件中时，插件状态信息保存在plugins_info.properties中的状态信息字段，排序号保存在plugins_info.properties中sortNum字段。plugins_info.properties表示插件排序信息记录文件可以和上述插件状态信息记录文件合并的文件。

步骤S32：对所述插件排序信息记录文件中的所述插件的排序号进行修改。

对所述插件排序信息记录文件中的所述插件的排序号进行修改具体为：

对所述插件排序信息记录文件中的所述插件的排序号的大小进行修改或删除所述插件排序信息记录文件中的所述插件的排序号。

在本实施例中，对插件的管理还包括对插件的更新，更新的过程请参见图4，在图1示出的插件管理方法的基础上还包括以下步骤：

步骤S13：将所述插件的状态修改为停止状态，并获取新版本的插件。

步骤S14：利用所述新版本的插件更新所述插件。

利用所述新版本的插件更新所述插件的具体过程可以为：将所述插件替换为所述新版本的插件；重新加载新版本的插件。

在本实施例中，对插件的管理还包括对插件的卸载，卸载的过程请参见图5，在图1示出的插件管理方法的基础上还包括以下步骤：

步骤S15：若所述插件的状态为运行状态，则停止运行所述插件，并将所述插件的状态修改为停止状态。

由于处于运行状态的插件不能被卸载，因此首先停止运行所述插件，并将所述插件的状态修改为停止状态。

步骤S16：卸载所述插件。

实施例二

与上述方法实施例相对应，本实施例提供了一种插件管理装置，请参见图6，插件管理装置包括：第一管理模块61和第二管理模块62。

第一管理模块61，用于对插件的状态进行管理。

第二管理模块62，用于对所述插件的排序进行管理。

在本实施例中，第一管理模块61具体可以包括：获取单元、第一确定单元、第一保存单元、第二确定单元、第二保存单元、判断单元和删除单元。

获取单元，用于获取所述插件所属web系统的运行状态和所述插件的加载状态。

第一确定单元，用于若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为加载完成状态，则确定所述插件的状态为运行状态。

第一保存单元，用于将表征运行状态的插件状态信息保存在插件状态信息记录文件中。

第二确定单元，用于若所述插件所属web系统的运行状态为启动状态且所述插件的加载状态为未被加载状态，则确定所述插件的状态为停止状态。

第二保存单元，用于将表征停止状态的插件状态信息保存在所述插件状态信息记录文件中。

判断单元，用于在确定所述插件的状态为停止状态后，判断所述插件是否被删除，若所述插件被删除，则执行删除单元。

所述删除单元，用于确定所述插件的状态为卸载状态，并删除所述插件状态信息记录文件中关于所述插件的插件状态信息。

在本实施例中，第二管理模块62具体可以包括：分配单元、第三保存单元和修改单元。

分配单元，用于为所述插件分配排序号。

第三保存单元，用于将分配得到的排序号保存在插件排序信息记录文件中。

修改单元，用于对所述插件排序信息记录文件中的所述插件的排序号进行修改。

在本实施例中，上述插件管理装置还可以包括：获取模块63和更新模块64，如图7所示。

获取模块63，用于将所述插件的状态修改为停止状态，并获取新版本的插件。

更新模块64，用于利用所述新版本的插件更新所述插件。

在本实施例中，上述插件管理装置还可以包括：停止模块65和卸载模块66，如图8所示。

停止模块65，用于若所述插件的状态为运行状态，则停止运行所述插件，并将所述插件的状态修改为停止状态。

卸载模块66，用于卸载所述插件。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种插件管理方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。