CN105204871B - 一种插件式开发方法和装置 - Google Patents

Abstract

本发明实施例提供了一种插件式开发方法和装置，涉及计算机技术领域，用以提高应用程序配置信息的灵活性及方便性。包括接收启动第一应用程序的指令；根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象；将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，并将所述加载配置对象后的配置信息更新至所述配置模型中。本发明实施例应用于SPRING框架中。

Description

一种插件式开发方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种插件式开发方法和装置。

背景技术

目前开发J2EE程序一般都习惯使用SPRING框架，且SPRING框架支持XML配置文件来进行配置对象的注册、AOP(Aspect Oriented Programming，面向切面编程)的实现、MVC(Model View Controller，模型－视图－控制器)的实现。其中，配置文件是指开启应用程序时，应用程序需要读取并加载的配置信息的集合，该配置文件通常为开发人员使用XML(Extensible Markup Language，可扩展标记语言)配置文件对配置数据进行编程后得到的文件。目前在各种应用平台中的应用程序，应用程序不可避免的要处理各种各样的配置信息。

现有技术中，一般根据不同的应用平台将配置信息写入到应用程序中，在应用程序运行的同时加载配置信息以实现相关配置。当前系统通过XML配置文件来实现应用程序的相关配置。

由于应用程序实现不同功能时需要不同的配置文件，应用程序运行时其对配置文件进行的是实时性操作，因此，应用程序运行时配置文件与应用程序的状态是相关的，当应用程序需要生成新的需求时，就需要开发人员手工的修改配置文件进行集成，在Java软件开发过程中，开发人员每次修改配置文件后需要重新编译，并封装为应用程序，然后重新启动应用程序，才能看到修改后的最终执行效果；某些应用程序的配置文件重新编译后，重新启动需要较长时间，故导致开发人员需要花费额外的精力来配置这些文件，人工介入的越多同样带来的错误也就越多，例如，若在应用程序运行时配置文件被人为删除或更改则会对应用程序的运行带来风险，尤其是对配置文件频繁删除或更改后，可能会使得应用程序无法正常。

发明内容

本发明的实施例提供一种插件式开发方法和装置，用以提高应用程序配置信息的灵活性及方便性。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明实施例提供一种插件式开发方法，包括:

接收启动第一应用程序的指令；

根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象；

将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中。

结合第一方面，在第一方面的第一种可能的实现方式中，所述方法还包括配置模型的生成过程，所述配置模型的生成过程包括：

提取至少一个开发框架不同配置文件中的配置信息；

将所述加载实现类除所述SPRING框架之外的配置信息，修改为符合SPRING框架的预设规范格式的配置信息将所述配置信息加载到所述SPRING容器中。

结合第一方面，在第一方面的第二种可能的实现方式中，所述从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类包括：

确定至少两个线程；通过所述至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；获取实现第一config接口的加载实现类。

结合第一方面，在第一方面的第三种可能的实现方式中，在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象之后，所述方法还包括：

生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述方法还包括：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

结合第一方面的第三种可能的实现方式，在第一方面的第五种可能的实现方式中，所述方法还包括：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

第二方面，本发明实施例还提供一种插件式开发装置，包括：

接收单元，用于接收启动第一应用程序的指令；

读取单元，用于根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

获取单元，用于从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

生成单元，用于在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象；

加载单元，用于将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中。

结合第二方面，在第二方面的第一种可能的实现方式中，所述装置还包括转换单元，所述转换单元具体用于：

提取至少一个开发框架不同配置文件中的配置信息；

将所述加载实现类除所述SPRING框架之外的配置信息，修改为符合SPRING框架的预设规范格式的配置信息将所述配置信息加载到所述SPRING容器中。

结合第二方面，在第二方面的第二种可能的实现方式中，所述获取单元具体用于：

确定至少两个线程；通过所述至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；获取实现第一config接口的加载实现类。

结合第二方面，在第二方面的第三种可能的实现方式中，所述装置还包括存储单元，所述存储单元具体用于：

生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述装置还包括配置调用单元，所述配置调用单元具体用于：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

结合第二方面的第三种可能的实现方式，在第二方面的第五种可能的实现方式中，所述装置还包括配置同步单元，所述配置同步单元具体用于：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

本发明实施例提供一种插件式开发方法，用于将原来需要在配置文件中体现的配置信息，通过第一config接口运行第一config接口对应的加载实现类后，生成所述加载实现类的配置对象；并将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，使得第一应用程序可以直接和配置对象进行数据交互，使得应用开发人员可以直接通过查看或操作配置对象对第一应用程序所需插件的参数设定或修改，且由于本发明实施中配置信息是由第一config接口运行第一config接口对应的加载实现类后，自动生成所述加载实现类的配置对象，很大程度减少开发人员的工作量，也避免了由于配置文件丢失或者将配置文件配置错误，导致第一应用程序无法运行的问题。

附图说明

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

图1为本发明实施例提供的一种应用场景示意图；

图2为本发明实施例提供的一种应用服务器的硬件结构图；

图3为本发明实施例提供的一种插件式开发方法的流程示意图一；

图4为本发明实施例提供的一种插件式开发方法的流程示意图二；

图5为本发明实施例提供的一种插件式开发方法的流程示意图三；

图6为本发明实施例提供的一种插件式开发方法的流程示意图四；

图7为本发明实施例提供的一种插件式开发装置的结构示意图。

具体实施方式

本发明实施例的基本原理在于：将原来需要体现在配置文件中的信息，通过第一config接口运行第一config接口对应的加载实现类后，生成所述加载实现类的配置对象，使得应用程序可以直接跟配置对象进行交互，将应用程序和配置文件之间的关系解耦。

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

如图1所示，示出了本发明实施例确定了插件式开发方法的实施环境的网络架构。该实施环境的系统可包括用户终端10、应用服务器20。其中，应用服务器20用于执行插件式开发装置。用户终端10与应用服务器20形成无线或有线连接，且用户终端10上具有相应的应用程序，用户终端10通过应用程序接收用户输入的请求，并将该请求发送给应用服务器20，从而可以触发应用服务器20执行插件式开发装置，以实现应用程序的相应功能。其中，用户终端10可以为PC、手机、iPAD，平板电脑、笔记本电脑、个人数字助理、可穿戴式移动电子终端如智能手表、眼镜等终端。

图2示出了上述应用服务器20的一种硬件结构图。如图2所示，该应用服务器20包括一个或多个(图中仅示出一个)处理器201、存储器202、用户接口203、网络接口204以及通信总线205。本领域普通技术人员可以理解，图2所示的结构仅为示意，其并不对应用服务器20的结构造成限定。例如，应用服务器20还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。

通信总线205用于应用服务器20中各组成部件之间的通信。用户接口203用于插接外部设备，例如触摸屏、鼠标及键盘等，以接收用户输入的信息。网络接口204用于应用服务器20与外部进行互相通信，该网络接口204主要包括有线接口和无线接口，例如RS232模块、射频模块、WIFI模块等等。

存储器202可用于存储软件程序以及模块，数据库，如本发明实施例中的插件式开发方法及装置对应的程序指令/模块。存储器202可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器202可进一步包括相对于处理器201远程设置的存储器，这些远程存储器可以通过网络连接至应用服务器20。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器201通过运行存储在存储器202内的软件程序以及模块，从而执行各种功能应用以及数据处理，例如，处理器201通过调用存储器202中的配置模型实现应用程序的相应功能。

本发明实施例提供了一种插件式开发方法，如图3所示，包括：

S101、接收启动第一应用程序的指令；

S102、根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

S103、从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

S104、在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象；

S105、将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中。

本发明实施例提供一种插件式开发方法，用于将原来需要在配置文件中体现的配置信息，通过第一config接口运行第一config接口对应的加载实现类后，生成所述加载实现类的配置对象；并将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，使得第一应用程序可以直接和配置对象进行数据交互，使得应用开发人员可以直接通过查看或操作配置对象对第一应用程序所需插件的参数设定或修改，且由于本发明实施中配置信息是由第一config接口运行第一config接口对应的加载实现类后，自动生成所述加载实现类的配置对象，很大程度减少开发人员的工作量也避免了由于配置文件丢失或者配置错误，导致第一应用程序无法运行的问题。

其中，本发明实施例对配置文件具体不进行限定，例如配置文件可以为XML文件或者数据库等，并将所述配置文件存储在SPRING容器中。

其中，本发明实施例中的第一应用程序是指安装在应用服务器上的任意一个应用程序。

其中，本发明实施例对预先配置的配置信息不进行限定，可以根据需要进行设定，例如，预先配置的配置信息可以包括但不限于：配置类注册、配置类数据初始化、配置类数据设置等。

示例性的，配置类数据初始化可以包括用于使得所述第一应用程序访问服务器、连接数据库、访问缓存等。

可选的，如图4所示，本发明实施例还包括配置模型的生成过程，所述配置模型的生成过程包括：

S1、提取至少一个开发框架不同配置文件中的配置信息；

S2、将所述加载实现类除所述SPRING框架之外的配置信息，按照修改为符合SPRING框架的预设规范格式的配置信息将所述配置信息加载到所述SPRING容器中。

其中，本发明实施例中对开发框架的具体形式不进行限定，例如，可以是SPRING框架、WEB(Web application framework)框架，由于每个开发框架都有一系列的配置文件，且每个配置文件的格式和协议不同，例如，配置文件的格式有XML、Properties、db等，本发明实施例通过提取至少两种开发框架的配置文件的配置信息，将提取到的按照SPRING框架预设规范格式加载至SPRING容器中，SPRING容器中加载了多个JavaBean，每个JavaBean都可以完成相应的功能，而对于其中的一个JavaBean而言，该JavaBean可以引用容器中加载的其他一个或几个JavaBean，也可以被容器中加载的其他一个或几个JavaBean所引用。

其中，本发明实施例对预设规范格式的具体格式不进行限定，用户可以根据实际需要进行设定，示例性的，本发明实施例的预设规范格式可以将多种格式不同的配置文件的配置信息，转换成相同格式的配置信息，例如，配置文件的配置信息格式为XML文件格式，这样可以实现各种应用程序之间的数据传输。

本实施例将格式相同的配置文件的配置信息置于SPRING容器中预先建立的配置文件中，以对应用程序的配置信息进行统一管理，当应用程序运行时，对配置信息进行解析，使应用程序加载与解析后的配置信息对应的样式或功能。

为了提高对第一应用程序中的多个JAR包的读取效率，本发明实施例中通过两个以上的线程来读取可以第一应用程序使用的JAR包，并从第一应用程序使用的JAR包中获取实现第一config接口的加载实现类。

本发明实施例对至少两个线程读取JAR包的方式不进行限定，示例性的，如图5所示，可以通过以下方式来实现：

S1031、确定至少两个线程；

S1032通过至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；

S1033、获取实现第一config接口的加载实现类。

其中，本发明实施例中对获取至少两个线程的方式不进行限定，可以通过应用服务器获取CPU的核数，将CPU的核数设定为线程数，也可以根据需要进行预先设置，将预先设置的线程数存储于内存中，在需要从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类时，应用服务器从内存中读取预先设置的线程数，本发明实施例对此不进行限定。

其中，对于步骤S1032，可以按照所述第一应用程序所使用的JAR包在队列中的起始位置以及结束位置的对应关系以及每个JAR包的大小，开启相应线程数，按照并行依次顺序逐列扫描的形式遍历所述JAR包；例如，可以通过逐列扫描的形式，给每个线程均分配一个JAR包，例如，总共确定有四个线程即线程1、线程2、线程3、线程4；第一列中确定有30个JAR包，则线程1用于获取第一个JAR包中的信息，线程2用于获取第二个JAR包中的信息，线程3用于获取第三个JAR包中的信息，线程4用于获取第四个JAR包中的信息，当四个线程中任意一个线程读取完然后JAR包中的信息后，则向下扫描剩余的JAR包的信息，直至获取到30个JAR包中的每个JAR包的信息，则获取实现第一config接口的加载实现类。

当第一应用程序运行时，根据所述第一应用程序所在的应用平台，由于每个应用平台具有不同的接口，通过不同的接口可以实现不同的功能，本发明实施例对接口类型不进行限定，示例性的，本发明实施例以config接口为例进行说明，其中，第一config接口为第一应用程序所在的应用平台上的任意一个接口。

其中，如图6所示，应用服务器获取到用户开启第一应用程序的启动指令，应用服务器从配置模型中获取运行第一应用程序需要的配置信息，以及需要实现的特定功能，例如，第一应用程序需要实现访问数据库、访问缓存等功能，然后应用服务器将第一应用程序的所有JAR包载入队列中，通过至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取可以实现第一应用程序需要实现的特定功能的JAR包，并在第一config接口上运行所述JAR包以获取加载实现类，并获取加载实现类中的配置信息，将获得的配置信息添加到配置模型中，应用服务器运行所述第一应用程序使得第一应用程序可以调用所述载实现类中的配置信息以实现相应的功能。

可选的，为了实现从所述第一config接口实现查找相应的加载实现类，在S104之后，本发明实施例还包括：

S105、生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

S106、将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

与现有技术不同的是，本发明实施例中通过生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系，不仅可以支持原生API通过加载实现类查找与该加载实现类对应的实现接口，且也可以支持反向的通过第一config接口查找到与所述第一config接口对应的加载实现类。

可选的，第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系可以实现提供在一存储装置中，这样当通过线程从第一应用程序中获取实现第一config接口的加载实现类时，可以利用与该加载实现类对应的第一config接口来生成配置对象。其中，本发明实施例对应关系的具体形式不进行限定，可以通过表格的形式进行存储于配置模型的调用索引，示例性的，如下表1所示：

第一config接口	第一加载实现类	第一配置对象
			第二config接口	第二加载实现类	第二配置对象
……	……	……

通过建立config接口、与所述config接口对应的加载实现类以及配置对象之间的对应关系，不仅可以方便的实现通过加载实现类查找到相应的config接口，而且可以通过config接口查找到相应的加载实现类，当需要改变任意一个config接口的功能时，可以通过查找与所述config接口对应的加载实现类以及配置对象，通过修改配置对象来实现相应的功能。

进一步的，本发明实施例所述方法还包括：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

当第一应用程序运行时，可以通过该配置调用API接口获取存储于SPRING容器中的配置对象。通过这种方法，可以改变现有技术中将配置信息写入应用程序的状况，将配置信息从应用程序的代码中分离出来，仅需要根据配置对象的接口规范，就能够实现获取配置对象。当获取第一config接口时，通过调用配置调用API接口调用加载实现类的进行解析获取配置对象，并将解析后的配置对象传递给第一应用程序使用。

进一步的，本发明实施例所述方法还包括：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

当接收到用户对配置对象进行修改的修改指令后，根据修改指令中用户输入的所述配置对象的更新值修改配置对象，应用程序的样式或功能随着已修改的配置对象变化，根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

其中，用户输入的所述配置对象的更新值可以为在配置对象中增加新的代码，在配置对象删除部分代码或修改配置对象中的代码以使得所述配置对象更新或者实现新的功能。

其中，可以在SPRING容器中设置相关的修改指令，通过上述配置同步API接口来修改配置对象。例如，当第一应用程序为浏览器时可以通过刷新浏览器页面以更改浏览器的样式或功能，其他的应用程序可以使用类似的操作达到修改配置对象后应用程序的样式或功能的更改。

实施例二

本发明实施例还提供一种插件式开发装置，该插件式开发装置中的各个功能单元与实施例一种插件式开发方法相对应，具体可以参考本发明实施例一种插件式开发方法实施例的描述，本发明实施例在此不再赘述。如图7所示，本发明实施例的插件式开发装置50，包括：

接收单元501，用于接收启动第一应用程序的指令；

读取单元502，用于根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

获取单元503，用于从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

生成单元504，用于在所述第一config接口运行所述第一config接口对应的加载实现类，生成所述加载实现类的配置对象；

加载单元505，用于将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中。

本发明实施例提供一种插件式开发装置，用于将原来需要在配置文件中体现的配置信息，通过第一config接口运行第一config接口对应的加载实现类后，生成所述加载实现类的配置对象；并将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，使得第一应用程序可以直接和配置对象进行数据交互，使得应用开发人员可以直接通过查看或操作配置对象对第一应用程序所需插件的参数设定或修改，且由于本发明实施中配置信息是由第一config接口运行第一config接口对应的加载实现类后，自动生成所述加载实现类的配置对象，很大程度减少开发人员的工作量，也避免了由于配置文件丢失或者配置错误，导致第一应用程序无法运行的问题。

进一步的，所述装置还包括转换单元，所述转换单元具体用于：

提取至少一个开发框架不同配置文件中的配置信息；

用于将所述加载实现类除所述SPRING框架之外的配置信息，按照修改为符合SPRING框架的预设规范格式的配置信息将所述配置信息加载到所述SPRING容器中。

进一步的，所述获取单元503具体用于：

获取至少两个线程；根据所述至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；获取实现第一config接口的加载实现类。

可选的，所述装置还包括存储单元，所述存储单元具体用于：

生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

当应用服务器启动时，可以将所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系自动存储在存储单元中，可以理解的是，该存储单元可以位于应用服务器中也可以位于客户端中，本发明实施例对此不进行限定。

进一步所述装置还包括配置调用单元，所述配置调用单元具体用于：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

进一步所述装置还包括配置同步单元，所述配置同步单元具体用于：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种插件式开发方法，其特征在于，包括：

接收启动第一应用程序的指令；

根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

在所述第一config接口运行所述第一config接口对应的加载实现类，生成加载实现类的配置对象；

将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中；

生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括配置模型的生成过程，所述配置模型的生成过程包括：

提取至少一个开发框架不同配置文件中的配置信息；

将所述加载实现类除SPRING框架之外的配置信息，修改为符合SPRING框架的预设规范格式的配置信息，将所述配置信息加载到所述SPRING容器中。

3.根据权利要求1所述的方法，其特征在于，所述从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类包括：

确定至少两个线程；通过所述至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；获取实现第一config接口的加载实现类。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。

6.一种插件式开发装置，其特征在于，包括：

接收单元，用于接收启动第一应用程序的指令；

读取单元，用于根据所述指令启动所述第一应用程序，并从配置模型中获取运行所述第一应用程序需要的配置信息，所述配置模型中包含预先配置的配置信息；

获取单元，用于从所述第一应用程序的JAR包队列中获取实现第一config接口的加载实现类；

生成单元，用于在所述第一config接口运行所述第一config接口对应的加载实现类，生成加载实现类的配置对象；

加载单元，用于将所述配置对象加载到所述运行所述第一应用程序需要的配置信息中，运行所述第一应用程序，并将所述加载配置对象后的配置信息更新至所述配置模型中；

存储单元，用于生成所述第一config接口、所述第一config接口的加载实现类以及所述配置对象之间的对应关系；

将所述对应关系添加至所述配置模型的调用索引中，所述调用索引包括至少一个对应关系，每个对应关系分别包含config接口、与所述config接口对应的加载实现类以及配置对象。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括转换单元，所述转换单元具体用于：

提取至少一个开发框架不同配置文件中的配置信息；

将所述加载实现类除SPRING框架之外的配置信息，修改为符合SPRING框架的预设规范格式的配置信息将所述配置信息加载到所述SPRING容器中。

8.根据权利要求6所述的装置，其特征在于，所述获取单元具体用于：

确定至少两个线程；通过所述至少两个线程并行依次的从所述第一应用程序的JAR包队列中，读取JAR包；获取实现第一config接口的加载实现类。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括配置调用单元，所述配置调用单元具体用于：

根据所述第一config接口查询所述调用索引，获得所述第一config接口对应的所述配置对象；

通过配置调用API接口调用所述加载实现类的配置对象。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括配置同步单元，所述配置同步单元具体用于：

通过配置同步API接口接收用户输入的所述配置对象的更新值；

根据所述配置对象的更新值重新加载所述第一应用程序，并更新所述第一config接口对应的所述配置对象。