CN106339237B - 针对JavaEE领域WEB应用的插件加载框架及方法 - Google Patents

Abstract

本发明公开了一种针对JavaEE领域WEB应用的插件加载框架及方法，包括：插件包检查准备模块，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要；插件包解压处理模块，用于当前插件PAR包需要解压时，将当前插件PAR包解压至指定的临时目录；资源加载模块，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作；可见，本方案通过抽象一种比标准WebApp更小的能包含各种WEB资源的管理单元—插件Par包，并通过提供对插件Par包的加载框架，以一种简单、方便的方式，实现在一个WebApp内部的简单方便的模块化管理方式。

Description

针对JavaEE领域WEB应用的插件加载框架及方法

技术领域

本发明涉及JavaEE技术领域，更具体地说，涉及一种针对JavaEE领域WEB应用的插件加载框架及方法。

背景技术

大型WEB应用系统传统的一体化开发管理方式，也就是整个WEB应用就一个工程，统一集成和发布，统一版本管理，会导致集成阶段效率低下、成功率低，而且在人员的分组管理，以及工程和代码的权限分配等方面管理复杂。针对JavaEE领域的WEB应用系统开发管理，解决上述问题，业界一般有几种选择，第一种是相对重量级的方案，也就是采用分布式服务化架构+单点登录机制。第二种做法是采用EAR(Enterprise Archive File)集成的方式来将多个WEB应用甚至EJB应用，集成到一起来运行。第三种做法是采用Servlet3.0规范的可插性支持，开发者可以在不修改已有Web应用的前提下，只需将按照一定格式打成的JAR包放到WEB-INF/lib目录下，即可实现新功能的扩充，不需要额外的配置。

然而，采用第一种分布式服务化架构+单点登录的方案，分布式架构必然比单一应用的架构要复杂，部署和运维的复杂度增加，尤其是在业务模块间耦合比较多的情况下，如果只是为了方便模块化分组管理而引入分布式架构，远程服务调用带来效率的损失，以及部署和运维复杂度的增加，会远远超过模块化分组管理带来的好处。业界通常只有在业务复杂度和并发请求达到一定的量级，单一应用集群的方式满足不了性能需求时，才会引入分布式架构。

采用第二种EAR集成方式最大的缺点就是对中间件的限制，由于EAR规范中允许包含EJB模块，所以它在普通的Servlet容器中无法运行，比如Tomcat中间件就不支持EAR规范，这就导致很多产品无法使用EAR集成方式。

采用第三种Servlet3.0规范可插性方案，也存在两方面的限制，一是这种机制需要有支持Servlet3.0规范的相应版本中间件，比如Tomcat需要7.0以上版本，比如Weblogic则需要12c以上版本，而业界目前还有很多应用是基于Servlet2.3以后规范的应用，尤其是很多电子政务类的应用。二是它只能针对web.xml中定义的内容，以及承载这些内容的资源，进行插件化管理，而对于其他WEB资源，比如页面资源(含html\js\css\jpg等)、第三方jar包等则不支持插件化分组管理。

因此，针对大型的WEB应用系统，如何提供一种简单方便的模块化管理方式是本领域技术人员需要解决的。

发明内容

本发明的目的在于提供一种针对JavaEE领域WEB应用的插件加载框架及方法，以实现提供一种简单方便的模块化管理方式。

为实现上述目的，本发明实施例提供了如下技术方案：

一种针对JavaEE领域WEB应用的插件加载框架，包括：

插件包检查准备模块，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

插件包解压处理模块，用于所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

资源加载模块，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作。

其中，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

其中，所述资源加载模块包括：

页面资源的加载器，用于将插件PAR包中的页面资源合并到WebApp的相应目录下；

Class加载器，用于利用相应的中间件的类加载器实现class的动态加载；

依赖jar包加载器，用于利用相应的中间件的类加载器实现依赖jar包的动态加载。

其中，所述插件包检查准备模块，包括：

唯一性检查单元，用于检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则触发提示单元；

所述提示生成单元，用于生成相应的提示信息。

一种针对JavaEE领域WEB应用的插件加载方法，包括：

检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

当所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作。

其中，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

其中，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为页面资源，则将插件PAR包中的页面资源合并到WebApp的相应目录下。

其中，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为Class，则利用相应的中间件的类加载器实现class的动态加载；

若资源文件为依赖jar包，则利用相应的中间件的类加载器实现依赖jar包的动态加载。

其中，还包括：

在WebApp的web.xml中配置插件专用过滤器，通过所述过滤器统一管理插件包中web.xml描述的filter、servlet，通过自定义的FilterChain实现对filter、servlet的映射匹配处理。

其中，计算并记录插件PAR包摘要之后，包括：

检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则生成相应的提示信息。

通过以上方案可知，本发明实施例提供的一种针对JavaEE领域WEB应用的插件加载框架，包括：插件包检查准备模块，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；插件包解压处理模块，用于所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；资源加载模块，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作；

可见，在本实施例中，通过抽象一种比标准WebApp更小的能包含各种WEB资源的管理单元—插件Par包，并通过提供对插件Par包的加载框架，以一种简单、方便的方式，实现在一个WebApp内部的模块化分组管理，以及若干个WebApp间通用基础模块的管理，能方便的实现大中型WEB应用系统内部的模块化管理；能方便的实现多个WEB应用系统之间通用基础模块的独立化管理，不需要引入复杂的分布式架构，不需要进行分布式远程调用，运行时还是部署一个WEB应用即可；能够在支持Servlet容器的中间件上运行，不需要专门支持EJB的应用中间件，比如Weblogic或Jboss。能够支持从Servlet2.3规范到Servlet3.0规范，支持中间件版本更多，不仅支持web.xml中定义的内容，以及这些内容需要使用的资源(包括class文件、配置文件等)，还支持页面资源(含html\js\css\jpg等)、第三方jar包、Spring配置、Struts配置等资源，还可以根据需要扩展对其它资源的插件化管理。

附图说明

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

图1为本发明实施例公开的分布式服务化架构+单点登录的方案结构示意图；

图2为本发明实施例公开的采用EAR(Enterprise Archive File)集成的方式结构示意图；

图3为本发明实施例公开的采用插件对模块化分组管理和通用基础模块管理结构示意图；

图4为本发明实施例公开的一种针对JavaEE领域WEB应用的插件加载框架结构示意图；

图5为本发明实施例公开的鲁棒图分析结构示意图；

图6为本发明实施例公开的一种针对JavaEE领域WEB应用的插件加载方法流程示意图。

具体实施方式

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

本发明实施例公开了一种针对JavaEE领域WEB应用的插件加载框架及方法，以实现提供一种简单方便的模块化管理方式。

参见图1，为第一种分布式服务化架构+单点登录的方案，具体做法是将一个大型WEB应用系统，分解成若干个WEB应用来开发，来实现模块化分组管理，并通过远程服务调用方式，实现分布式部署和集成运行。另一方面将若干WEB应用的通用基础模块，也提炼成一个单独的WEB应用来开发和运行。在这种架构下，原本一个WEB应用内部模块间的调用和依赖，以及各个WEB应用对通用基础模块的调用和依赖，都需要转换成WEB应用之间的远程服务调用。同时用户原本对一个WEB应用的访问，需要转换成对多个WEB应用的访问，为了避免给用户造成麻烦，这种架构下一般又需要引入单点登录机制，来集成多个WEB应用的运行态。

参见图2，第二种做法是采用EAR(Enterprise Archive File)集成的方式，具体做法也是将一个大型WEB应用系统，分解成若干个WEB应用来开发，但运行时不需要远程服务调用，而是将若干WEB应用集成到一个EAR包中来运行，这样可以直接本地类依赖调用。另一方面将若干WEB应用的通用基础模块，也提炼成一个单独的WEB应用来开发，运行时集成到具体产品的EAR包中来运行。这种机制虽然不需要远程服务调用，但无法避免单点登录集成，而且EAR包的运行需要应用服务器中间件的支持，比如Weblogic或JBoss等，它不能在Tomcat这类普通Servlet容器中运行。

第三种做法采用Servlet3.0规范的可插性支持，开发者可以在不修改已有Web应用的前提下，只需将按照一定格式打成的JAR包放到WEB-INF/lib目录下，即可实现新功能的扩充，不需要额外的配置。Servlet 3.0规范引入了称之为“Web模块部署描述符片段”的web-fragment.xml部署描述文件，该文件必须存放在JAR文件的META-INF目录下，该部署描述文件可以包含一切可以在web.xml中定义的内容。JAR包通常放在WEB-INF/lib目录下，除此之外，所有该模块使用的资源，包括class文件、配置文件等，只需要放在能够被容器的类加载器链加载的路径上，比如classes目录等。这种机制需要有支持Servlet3.0规范的相应版本中间件，比如Tomcat需要7.0以上版本，以及Weblogic需要12c以上版本。而且它只能针对web.xml中定义的内容，以及承载这些内容的资源，进行插件化管理，而对于其他WEB资源，比如页面资源(含html\js\css\jpg等)、第三方jar包等则不支持插件化分组管理。

然而，无论是采用第一种分布式服务架构还是第二种EAR集成架构，都是将WebApp对应的War包当做最小单元来管理，而本发明提供的插件加载框架，目的则是用来管理比WebApp更小的单元——插件，将一组模块对应的资源定义成一个插件，包括页面资源、java代码和配置等内容。通过这种模式，就可以将一个WebApp分解为若干个插件，实现简单方便的模块化分组管理和通用基础模块的管理，然后运行时再将插件集成到WebApp内部去运行，对外是一个完整的WebApp。

参见图3，在本实施例中采用插件的方式来解决模块化分组管理和通用基础模块管理，带来的好处就是，由于运行时是多个插件集成为一个WebApp来运行，所以不需要像分布式架构那样需要进行远程服务调用，由于采用标准的WebApp作为运行时的形态，所以不需要像EAR集成方式那样需要依赖专门的应用服务器中间件，在标准Servlet容器上就可以运行。同时由于Servlet3.0规范的可插性支持，需要对Servlet容器有较高的版本限制，并且对页面资源(含html\js\css\jpg等)、第三方jar包等不支持插件化管理。

所以本发明的目的就是通过自行定义一套插件包的格式，使其能够包含一个WEB应用中常见的页面资源、Java代码、配置、依赖jar包等资源，同时提供一套针对该格式插件包的自定义加载框架，使得系统运行时能够自动完成将多个插件包内容合成到标准WebApp的过程，并且支持在Servlet2.3及以上版本容器中运行。

在本方案中，首先自行定义一套用来包含页面资源(含html\js\css\jpg等)、Java代码、配置、依赖jar包等资源的插件PAR包格式，如下：

pages--页面资源目录

styles--页面样式目录

scripts–页面js脚本目录

…

web-inf--webinf目录

classes--class目录，可以包括spring配置

lib--依赖第三方jar包目录

iitms.mall.cq.jar

httpclient4.4.1.jar

…

struts--struts配置目录

XX_ParWeb.xml--插件web.xml描述文件，用来申明插件中的servlet和filter

从这个内部结构中，可以看出一个业务模块组对应的插件包中，包含该业务模块组所需的页面资源、JAR包、struts配置、特色web.xml描述文件等。

模仿EAR(Enterprise Archive File)、WAR(Web Archive File)、JAR(JavaArchive File)等的命名风格，在本实施例中将这种格式的插件包命名为PAR包(PluginArchive File)，对应插件程序归档文件的简称。

针对本实施例自行定义的这套插件包格式与规范，需要同时提供一套针对该格式插件包的加载框架，使得系统运行时能够自动完成将多个插件包内容合成到标准WebApp的过程。这套插件包的加载框架需要实现以下功能：

插件包检查准备模块：格式检查和唯一性检查；

插件包解压处理模块：发布痕迹记录，摘要对比，Par包解压和文件搬移；

资源加载模块：页面资源加载器，Jar包加载器，Web.xml加载器和struts/spring等配置加载。

参见图4，本发明实施例提供的一种针对JavaEE领域WEB应用的插件加载框架，包括：

插件包检查准备模块100，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

具体的，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

其中，所述插件包检查准备模块，包括：

唯一性检查单元，用于检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则触发提示单元；

所述提示生成单元，用于生成相应的提示信息。

具体的，如前文所述对于插件PAR包来说具有一套自定义的格式，其内部包含页面资源、jar包、struts、spring配置等，所以有必要在插件加载和运行之前，先对其格式进行检查；并且由于一个WebApp中允许包含多个插件包，所以针对class、jar包、struts、spring配置等进行唯一性检查也是非常必要的，以避免冲突。

插件包解压处理模块200，用于所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

具体的，在本实施例中，对于包含各种WEB资源的插件PAR包来说，Par包实际是一个压缩包，所以在加载WEB资源之前显然要先进行解压处理，同时要将解压后插件包中的相关资源文件放到合适的临时目录下。同时为了在应用启动时，应该借鉴war包的加载模式，每次检测到新的插件包时，要记录相应的解压痕迹和插件包摘要，下次启动时，只要比较下摘要，就可以判断插件是否发生变化，是否需要解压处理。

资源加载模块300，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作。

其中，所述资源加载模块包括：

页面资源的加载器，用于将插件PAR包中的页面资源合并到WebApp的相应目录下；

Class加载器，用于利用相应的中间件的类加载器实现class的动态加载；

依赖jar包加载器，用于利用相应的中间件的类加载器实现依赖jar包的动态加载。

具体的，资源加载模块300提供各种WEB资源的加载功能，也就是针对插件包中的各项资源文件在WEB应用启动时进行合成与加载，针对页面资源、Jar包、struts配置、spring配置等不同的资源，需要有不同的加载器，同时允许针对新的资源，扩展相应的加载器。为了实现前文所述的这些功能，利用鲁棒图分析结构如图5。

可见，本框架的入口边界模块是启动模块，它负责完成所有插件包的载入，确保中间件在加载WebApp时，能够识别并启动本框架，以listener、servlet、filter等方式在WebApp中启动本框架。

具体的，在本方案中，针对页面资源的加载器，逻辑最简单，只需要将pages、styles、scripts等页面资源目录，合并到WebApp的相应目录下即可。针对class和依赖第三方jar包的加载器，需要利用不同中间件的类加载器(ClassLoader)，来分别实现相应的动态加载。针对插件包中web.xml的加载器，需要在WebApp的web.xml中配置好插件专用过滤器，在该过滤器中统一管理插件包中web.xml描述的filter、servlet，它拦截所有请求，并通过自定义的FilterChain实现对这些filter、servlet的映射匹配处理，在WebApp中配置的其他filter、servlet之前优先执行。针对sturts配置和spring配置，也分别需要实现相应的加载器。

综上，在本方案的插件包解压处理过程中，通过记录和比对摘要，判断插件包是否有变化，是否要处理，来加速启动的过程。通过对不同WEB资源加载器的抽象，使得WEB资源的加载结构清晰并具有可扩展性，针对新的WEB资源不会导致插件加载框架的结构性变化，保证框架的稳定性。而针对class和依赖第三方jar包的加载器、针对插件包中web.xml的加载器，是插件包能作为独立管理WEB资源的最小单元的核心技术。

下面对本发明实施例提供的插件加载方法进行介绍，下文描述的插件加载方法与上文描述的插件加载框架可以相互参照。

参见图6，本发明实施例提供的一种针对JavaEE领域WEB应用的插件加载方法，包括：

S101、检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

具体的，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

S102、当所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

S103、在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作。

基于上述技术方案，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为页面资源，则将插件PAR包中的页面资源合并到WebApp的相应目录下。

基于上述技术方案，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为Class，则利用相应的中间件的类加载器实现class的动态加载；

若资源文件为依赖jar包，则利用相应的中间件的类加载器实现依赖jar包的动态加载。

基于上述技术方案，本方案还包括：

在WebApp的web.xml中配置插件专用过滤器，通过所述过滤器统一管理插件包中web.xml描述的filter、servlet，通过自定义的FilterChain实现对filter、servlet的映射匹配处理。

基于上述技术方案，计算并记录插件PAR包摘要之后，包括：

检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则生成相应的提示信息。

本发明实施例提供的一种针对JavaEE领域WEB应用的插件加载框架，包括：插件包检查准备模块，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；插件包解压处理模块，用于所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；资源加载模块，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作；

可见，在本实施例中，通过抽象一种比标准WebApp更小的能包含各种WEB资源的管理单元—插件Par包，并通过提供对插件Par包的加载框架，以一种简单、方便的方式，实现在一个WebApp内部的模块化分组管理，以及若干个WebApp间通用基础模块的管理，能方便的实现大中型WEB应用系统内部的模块化管理；能方便的实现多个WEB应用系统之间通用基础模块的独立化管理，不需要引入复杂的分布式架构，不需要进行分布式远程调用，运行时还是部署一个WEB应用即可；能够在支持Servlet容器的中间件上运行，不需要专门支持EJB的应用中间件，比如Weblogic或Jboss。能够支持从Servlet2.3规范到Servlet3.0规范，支持中间件版本更多，不仅支持web.xml中定义的内容，以及这些内容需要使用的资源(包括class文件、配置文件等)，还支持页面资源(含html\js\css\jpg等)、第三方jar包、Spring配置、Struts配置等资源，还可以根据需要扩展对其它资源的插件化管理。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种针对JavaEE领域WEB应用的插件加载框架，其特征在于，包括：

插件包检查准备模块，用于检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

插件包解压处理模块，用于所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

资源加载模块，用于在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作；其中，在WebApp的web.xml中配置插件专用过滤器，通过所述过滤器统一管理插件包中web.xml描述的filter、servlet，通过自定义的FilterChain实现对filter、servlet的映射匹配处理。

2.根据权利要求1所述的插件加载框架，其特征在于，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

3.根据权利要求2所述的插件加载框架，其特征在于，所述资源加载模块包括：

页面资源的加载器，用于将插件PAR包中的页面资源合并到WebApp的相应目录下；

Class加载器，用于利用相应的中间件的类加载器实现class的动态加载；

依赖jar包加载器，用于利用相应的中间件的类加载器实现依赖jar包的动态加载。

4.根据权利要求2或3所述的插件加载框架，其特征在于，所述插件包检查准备模块，包括：

唯一性检查单元，用于检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则触发提示生成单元；

所述提示生成单元，用于生成相应的提示信息。

5.一种针对JavaEE领域WEB应用的插件加载方法，其特征在于，包括：

检查插件PAR包的规范格式，计算并记录插件PAR包摘要，并根据记录结果判断当前插件PAR包是否需要解压；其中，每个插件PAR包中包括对应的业务模块组所需的资源文件；

当所述当前插件PAR包需要解压时，将所述当前插件PAR包解压至指定的临时目录；

在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作；

在WebApp的web.xml中配置插件专用过滤器，通过所述过滤器统一管理插件包中web.xml描述的filter、servlet，通过自定义的FilterChain实现对filter、servlet的映射匹配处理。

6.根据权利要求5所述的插件加载方法，其特征在于，每个插件PAR包中至少包括对应的业务模块组所需的页面资源、Java代码、class、struts、spring配置、依赖jar包。

7.根据权利要求6所述的插件加载方法，其特征在于，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为页面资源，则将插件PAR包中的页面资源合并到WebApp的相应目录下。

8.根据权利要求7所述的插件加载方法，其特征在于，所述在WEB应用启动时，通过每种类型的资源文件所对应的加载器，进行资源文件搬移工作和动态加载工作，包括：

若资源文件为Class，则利用相应的中间件的类加载器实现class的动态加载；

若资源文件为依赖jar包，则利用相应的中间件的类加载器实现依赖jar包的动态加载。

9.根据权利要求6-8中任意一项所述的插件加载方法，其特征在于，计算并记录插件PAR包摘要之后，包括：

检查所有插件PAR包中class、依赖jar包、struts、spring配置的唯一性，若存在唯一性问题，则生成相应的提示信息。