CN102929597B - 一种基于Java平台的Web业务支持方法和装置 - Google Patents

Abstract

本发明实施例公开了一种基于Java平台的Web业务支持方法和装置，属于计算机领域。方法包括：新建自定义类加载器，将自定义类加载器继承指定的父类加载器；采用自定义类加载器在预设的存储位置加载java程序类和资源；采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器。本发明管理人员只需要采用自定义的类加载器加载指定位置的Java类文件，使应用服务器和业务系统实现分离，避免了和应用服务器之间出现兼容性问题的可能，实现可持续增加新功能；在需求变更的情况下，使维护成本最小化，提高了Web业务系统的性能和服务质量。

Description

一种基于Java平台的Web业务支持方法和装置

技术领域

本发明涉及计算机领域，尤其涉及一种基于Java平台的Web业务支持方法和装置。

背景技术

随着经济发展，现代企业规模逐渐扩大，涉及到的业务领域也越来越广泛。企业需要有效手段来管理企业业务。越来越多的企业开始将日常处理的业务梳理为流程，通过规范化的流程来管理企业的日常运作。

业务流程是一系列有组织的活动，它们之间互相联系，为客户创造价值，为企业创造利润。业务流程管理是以业务流程为中心的管理思想。众多的企业将业务流程管理作为企业管理的重点。辅助企业进行业务流程管理的软件信息系统也成为重要的企业管理平台。这就需要我们的业务系统有能够快速的支持对企业用户的新需求进行快速支持的能力，然而传统的业务系统而言有以下问题：

1)、不同企业用户使用的应用服务器的不统一，很容易出现程序兼容性的问题；尤其是针对企业用户新需求而开发的流程的新功能而言更是如此；

2)、只专注于对已知的用户需求做很好的支持，而没有对企业用户的新需求做很好的设计支持或者没有形成可持续增加新功能的基础底层架构。这就导致对于传统的业务系统而言，要支持用户越来越丰富的新的功能应用要求来说是相当困难的一件事情，并且后期的维护成本也很高；

3)、由于大型企业用户上线的有业务流程管理功能的系统是多套，每套系统基本上都是业务流程管理功能的重复；这导致用户对于业务流程管理的通用功能做变更的话，就要把同样的变更在各个业务系统上做几乎同样的工作，而且由于不同Java应用服务器之间的差异性，直接导致增加用户的维护成本。

发明内容

本发明实施例提供一种基于Java平台的Web业务支持方法及装置，使应用服务器和业务系统实现分离，业务系统不依赖于应用服务器，避免了两者间出现兼容性问题的可能，且在需求变更的情况下，将维护成本最小化。

为达到上述目的，采用如下技术方案：

一种基于Java平台的Web业务支持方法，包括：

新建自定义类加载器，将自定义类加载器继承指定的父类加载器；

采用自定义类加载器在预设的存储位置加载java程序类和资源；

采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器。

优选的，所述采用自定义类加载器在预设的存储位置加载java程序类和资源，包括：

将新建的自定义类加载器的加载路径设置为自定义的存储路径；

将所述新建的自定义类加载器实例化；

设置所述新建的自定义类加载器的加载行为，所述自定义类加载器加载在自定义的存储路径上保存的Java程序类和资源；

运行实例化后的新建的自定义类加载器。

优选的，所述采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器，包括：

将所述加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性；

将所述加载Java程序类和资源后的自定义类加载器加载至Java平台内核中，替换Java平台内核中指定的已加载的类加载器。

优选的，所述Web应用程序加载类为WebappXClassLoader。

本发明还公开了一种基于Java平台的Web业务支持装置，包括：

建立单元，用于新建自定义类加载器，将自定义类加载器继承指定的父类加载器；

第一加载单元，用于采用自定义类加载器在预设的存储位置加载java程序类和资源；

第二加载单元，采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器。

优选的，所述第一加载单元采用自定义类加载器在预设的存储位置加载java程序类和资源，包括：

将新建的自定义类加载器的加载路径设置为自定义的存储路径；

将所述新建的自定义类加载器实例化；

设置所述新建的自定义类加载器的加载行为，令所述自定义类加载器加载在自定义的存储路径上保存的Java程序类和资源；

运行实例化后的新建的自定义类加载器。

优选的，所述第二加载单元采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器，包括：

将所述加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性；

将所述加载Java程序类和资源后的自定义类加载器加载至Java平台内核中，替换Java平台内核中指定的已加载的类加载器。

优选的，所述第二加载单元将加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性，包括：将加载Java程序类和资源后的自定义类加载器设置为WebappXClassLoader的成员属性。

本发明实施例提供的一种基于Java平台的Web业务支持方法和装置，管理人员只需要采用自定义的类加载器加载指定位置的Java类文件，并采用加载Java类文件后的类加载器替换Java平台内核中指定的类加载器，即可采用升级后的Java类文件直接替换原有的Java类文件，从而实现了Web业务系统的动态升级，使应用服务器和业务系统实现分离，避免了和应用服务器之间出现兼容性问题的可能，实现可持续增加新功能；在需求变更的情况下，使维护成本最小化，提高了Web业务系统的性能和服务质量。

附图说明

图1为本发明提供的一种基于Java平台的Web业务支持方法的步骤流程图；

图2为本发明提供的一种基于Java平台的Web业务支持装置的结构模块图。

具体实施方式

下面结合附图对本发明实施例一种基于Java平台的Web业务支持方法及装置进行详细描述。

在传统的WEB应用开发中，开发的程序都是借助于应用服务器提供的方式和类加载方式加载开发的应用，这就使程序容易产生对应用服务器的依赖，不同的系统则容易出现兼容性问题。在应用服务器中部署的业务系统在加载级别上是最低的，不同的应用服务器都会根据自身的实现方式在应用服务器自身级别的类加载器和应用服务器进行加载，这两个级别上将分别放置不同的第三方程序代码；这就产生以下问题：1)这时处于WEB级别的业务系统如果使用了和放置在其自己加载级别以上(通常情况下为应用服务器自身级别的类加载器和应用服务器中代码级的类加载器)的第三方程序，那么根据Java类加载器的加载方式，会加载放置在应用服务器这一级别上的第三方程序，而与第三方程序版本冲突的话则会影响业务系统的运行和使用；2)不同的应用服务器或者同一应用服务器的不同版本，在其应用服务器自身级别的类加载器和应用服务器中代码级的类加载器的对应位置，所放入要加载的第三方程序往往是不同的，业务系统没有办法进行统一。例如：应用服务器自身要有其能解析应用服务器自身配置文件的解析程序，如果用户的需求是要求业务系统也要有同样功能的解析配置文件的解析类，这样在整个应用中就会有这两个解析配置文件的程序。由Java其自身类加载的加载策略可以得知，在解析程序时，总是会使用比较上层应用服务器上的解析程序。在调用解析时就会调用应用服务器提供的解析程序，而没有使用程序预置的解析程序；同时又不能把该解析程序删除，在实际应用中这两个解析程序的版本可能发生冲突。

Java程序的运行是通过Java虚拟机进行的，Java程序就是一系列类文件的集合，类加载器就是把这一系列类文件加载到Java虚拟机中运行的关键类，Java自身的类加载器是根据应用服务器的位置按照委托代理的模式去加载的程序；要实现应用服务器和业务系统的程序代码级的分离部署，就需要让自定义的类加载器能加载不依赖应用服务器的指定位置的类定义，也就是说加载应用服务器之外的程序类定义，而这些类定义是业务流程系统的核心代码。

本发明实施例中，重写了类加载方法，即重新定义了Java类文件的加载方式，实现Java类文件(如，Jar包)的动态加载，具体为：新建一个自定义的类加载器，令新建的类加载器继承指定的父类加载器，且将该父类加载器设置为空值，再采用新建的类加载器在预设存储位置加载至少一个Java类文件，并采用加载Java类文件后的类加载器替换Java平台内核中指定的已加载的类加载器。

基于Java平台的Web业务系统内，所有的Java类文件在加载的时候，都是通过内置的类加载器(ClassLoader)来实现加载工作的，ClassLoader加载过程本身具有一定的层次与关系。以BootStrapClassLoader、ExtClassLoader、AppClassLoader以及用户自定义的CustomClassLoader，这四种类加载器为例，这四种类加载器分别负责不同路径的Java类文件的加载，并形成了一个类加载器的层次结构：

BootStrapClassLoader处于类加载器层次结构的最高层，负责Sun.boot.class.path路径下Java类文件的加载，默认为jre/lib目录下的核心API(应用程序接口)或-Xbootclasspath选项指定的Java类文件。

ExtClassLoader处于类加载器层次结构的次高层，负责java.ext.dirs路径下的Java类文件的加载，默认为jre/lib/ext目录或者-Djava.ext.dirs指定目录下的Java类文件。

AppClassLoader处于类加载器层次结构的次低层，负责java.class.path下Java类文件的加载，默认为环境变量CLASSPATH中设定的值。

用户自定义CustomClassLoader处于类加载器层次结构的最低层，可以根据用户的需要定制自己的类加载过程，在运行期进行指定Java类文件的动态实时加载。

上述四种类加载器形成一定的父子关系，高层为低层的父加载器，在进行Java类文件的加载时，系统首先会在类加载器层次结果中自底向上挨个检查是否已经加载了指定的Java类文件，如果已经加载则直接返回该Java类文件的引用，如果检查到最高层也没有加载过指定的Java类文件，那么系统会自顶向下逐个尝试加载指定的Java类文件，直到检索到用户自定义的类加载器CustomClassLoader，如果还不能加载成功，就会出现异常。

同一个类加载器实例而言，名字相同的Java类文件只能存在一个，并且仅能加载一次，不管该Java类文件有没有变化，下次再需要加载时，只能从自身的缓存中直接返回已经加载过的Java类文件的引用。

本发明实施例中，如图1所示，实现基于一种Java平台的Web业务支持方法的详细流程如下：

步骤101：新建自定义类加载器，将自定义类加载器继承指定的父类加载器；

本实施例中，将新建的自定义的类加载器命名为DynamicClassLoader。本实施例中，DynamicClassLoader继承的指定的父类加载器为CustomClassLoader，并将CustomClassLoader的取值设置为nulI值，这样，可以改变原始的加载顺序，即原先由父类加载器先加载Java类文件，再由子类加载器加载Java文件，改为先由子加载器加载Java类文件，再由父类加载器加载Java类文件，从而将原始的类加载顺序修改成为自定义的类加载顺序。

步骤102：采用自定义类加载器在预设的存储位置加载java程序类和资源；

本步骤包括：

A、将新建的自定义类加载器的加载路径设置为自定义的存储路径；

业务系统使用的第三方开源程序类和资源、以及业务系统自己的程序类和资源放置在业务系统的安装位置，并且该安装位置可以随意指定，而不依赖应用服务器的安装位置，从而在物理层面上进行了有效的部署。

例如：应用服务器安装在[D:\ApplicationServer]，业务系统安装在[E:\BusinessProcessManagement]，然后在应用服务器上的自定义配置文件记载业务系统的位置，在应用服务器的配置文件名可以为[MochaBPM-install.properties]中记录[mocha.BPM.install.path＝E:\BusinessProcessManagement]，业务系统在启动的时候得到该配置，就可以使用自定义的类加载器加载到业务系统的程序类和资源了。

B、将所述新建的自定义类加载器实例化。

例如：用户交互界面的代码放置在应用服务器类加载最底层级的WebappXClassLoader级别下，加载自定义类加载器的服务管理类ServiceManager放置在应用服务器的次低层类加载器SharedClassLoader上，在应用服务器启动的时候，会依次加载并启动WebappXClassLoader下的用户交互界面的应用；而在用户交互界面启动的时候会自动调用放置在应用服务器的SharedClassLoader上的ServiceManager去读取文件[MochaBPM-install.properties]中的属性[mocha.BPM.install.path]，找到业务流程管理系统的安装位置[E:\BusinessProcessManagement]，然后分别加载和实例化以应用服务器的次低层类加载器为父结构的自定义类加载器MochaBPM-Lib-ClassLoader和以MochaBPM-Lib-ClassLoader为父结构的自定义类加载器MochaBPM-App-ClassLoader。

C、设置所述新建的自定义类加载器的加载行为，令所述自定义类加载器加载在自定义的存储路径上保存的Java程序类和资源；

例如：MochaBPM-Lib-ClassLoader自定义类加载器设定为负责加载业务流程管理系统[E:\BusinessProcessManagement]下子目录[thirdLib\]中所放置的第三方开源程序类和资源，MochaBPM-App-ClassLoader自定义类加载器设定为负责加载业务流程管理系统[E:\BusinessProcessManagement]下子目录[appLib\]中放置的业务核心代码。

D、运行实例化后的新建的自定义类加载器。

自定义类加载器MochaBPM-Lib-ClassLoader和MochaBPM-App-ClassLoader将通过业务流程类路径获取器得到的第三方开源的程序类和资源、以及业务系统自身的程序类和资源加载到业务系统的自定义类加载器中。

优选的，业务系统的自定义类加载器加载具体的程序类和资源时，具体逻辑为：

a)业务系统的类加载器加载自定义程序类和资源时，首先在业务流程管理系统自身搜索加载程序和资源。

b)如果没有找到，业务系统的自定义类加载器才会去通过其上级类加载器去加载程序类和资源，让其上级父类加载器去加载要加载的程序类和资源。

c)业务系统的自定义类加载器其上级类加载器根据自生配置按照其自定义的加载方式再去加载程序类和资源。

d)使用自定义的类加载方式，让程序和资源首先在业务流程管理系统内先加载，而不是直接委托上级父类加载的方式；这样就解决了程序在加载时产生的逻辑层面的依赖。

步骤103：采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器。

本步骤包括：

将所述加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性；

捋所述加载Java程序类和资源后的自定义类加载器加载至Java平台内核中，替换Java平台内核中指定的已加载的类加载器。

需要改变Web服务器中的Java平台的类加载方式，令Web服务器将加载Java类文件后的类加载器重载至的Java平台内核中，替换Java平台内核中指定的已加载的类加载器，从而完成了Java类文件的热替换。

每一种Web服务器上运行的Java平台都有自身的类加载方式，以Web服务器是TomcatServer为例，TomcatServer在启动的时候将构造一个类加载器树，假设其层次和关系分别是：

BootStrapClassLoader-＞SystemClassLoader-＞CommonClassLoader-＞CatalinaClassLoader-＞SharedClassLoader-＞Web应用程序WebappXClassLoader(用于加载Web应用程序的类加载器)。

其中，WebappXClassLoader为一种Web应用程序加载类，用于加载在/WEB-INF/classes目录里所有的未包装的Java类和资源，对每个TomcatServer里的Web应用都创建一个WebappXClassLoader，Web应用下的WEB-INF/classes，WEB-INF/lib都由WebappXClassLoader加载，它所加载的Java类文件对其他的Web应用是不可见的。如，某一业务系统的应用程序组件与包(由多个类文件组成)是安装在/WEB-INF/classes与WEB-INF/lib下面的，而WebappXClassLoader负责这个业务系统的所有应用程序组件与包的加载。

从上可知，要想改变Web服务器上Java平台的类加载方式，就需要改造TomcatServer的类加载器树形结构类，具体过程如下：将新建的已加载了Java类文件的类加载器DynamicClassLoader作为AppClassLoader子类加载器；添加重建方法，令TomcatServer在重新加载时，采用重载的类加载器DynamicClassLoader，替换掉Java平台内核中指定的已加载的类加载器，修改loadClass方法，由于外层升级类组件需要调用DynamicClassLoader类中的loadClass方法实现动态升级类组件，将loadClass方法属性修改成为public，添加相关的代码，从而将重建的属性加入相关的地方。

以Web服务器Tomcat为例：

BootStrapClassLoader-＞SystemClassLoader-＞CommonClassLoader-＞CatalinaClassLoader-＞SharedClassLoader-＞WebappXClassLoader(Web应用程序)。

BootStrapClassLoader处于类加载器层次结构的最高层，负责Sun.boot.class.path路径下Java类文件的加载，默认为jre/lib目录下的核心API(应用程序接口)或-Xbootclasspath选项指定的Java类文件。

SystemClassLoader处于类加载器层次结构的次高层，负责java.class.path下Java类文件的加载，默认为环境变量CLASSPATH中设定的值。

CommonClassLoader处于类加载器层次结构的次低层，负责加载TomcatServer应用服务器自身需要的程序类文件，可以被具体应用调用并使用，默认路径是[Tomcat安装路径]/common/。

CatalinaClassLoader处于类加载器层次结构第四层，负责加载TomcatServer应用服务器自身需要的程序类文件，但是不可以被具体应用调用并使用。

SharedClassLoader也处于类加载器层次结构的次低层，和CatalinaClassLoader并列，但是顺序此CatalinaClassLoader靠后；负责加载TomcatServer给具体应用使用的程序类文件，这些程序类文件TomcatServer自身并不使用。

WebappXClassLoader处于处于类加载器层次结构的最低层，负责加载各个不同的具体WEB应用，具体加载每个应用WEB-INF/classes和WEB-INF/lib下的程序类和资源文件。

由以上结构，在本发明中，业务系统有三部分内容和TomcatServer对应：1)用户交互界面，即具体的WEB应用，不包含具体的业务逻辑；2)业务流程管理系统核心代码，安装在[E:\BusinessProcessManagement]；3)服务管理类ServiceManager，负责在TomcatServer中调用自定义类加载器DynamicClassLoader加载业务流程管理系统的核心代码，放置在TomcatServer的SharedClassLoader这个加载其中，可以给TomcatServer下的多个WEB应用同时提供业务流程管理系统的支持。

具体过程如下：在TomcatServer启动时，

1.依次加载并启动WebappXClassLoader下的WEB的应用。

2.WEB应用启动的时候会自动调用放置在应用服务器的SharedClassLoader上的ServiceManager去读取文件[MochaBPM-install.properties]中的属性[mocha.BPM.install.path]，找到业务系统的存储路径[E:\BusinessProcessManagement]。

3.分别加载和实例化以SharedClassLoader为父结构的自定义类加载器MochaBPM-Lib-ClassLoader和以MochaBPM-Lib-ClassLoader为父结构的自定义类加载器MochaBPM-App-ClassLoader，即[SharedClassLoader]-＞[MochaBPM-Lib-ClassLoader]-＞[MochaBPM-App-ClassLoader]。

4.MochaBPM-Lib-ClassLoader自定义类加载器预设为负责加载业务系统[E:\BusinessProcessManagement]下子目录[thirdLib\]中所放置的第三方开源程序类和资源，MochaBPM-App-ClassLoader自定义类加载器设定为负责加载业务系统[E:\BusinessProcessManagement]下子目录[appLib\]中放置的业务核心代码。

5.WEB应用相应用户请求时，会通过在SharedClassLoader中的ServiceManager去MochaBPM-App-ClassLoader中寻找加载的java程序类和资源。

6.MochaBPM-App-ClassLoader需找被请求的java程序类和资源时，首先在其MochaBPM-App-ClassLoader自身中搜索加载程序和资源。

7.MochaBPM-App-ClassLoader如果没有找到，MochaBPM-App-ClassLoader会通过其父类加载器MochaBPM-Lib-ClassLoader去加载java程序类和资源。

8.MochaBPM-Lib-ClassLoader需找被请求的程序类和资源时，首先在其MochaBPM-Lib-ClassLoader自身中搜索加载java程序类和资源；如果没有找到，MochaBPM-Lib-ClassLoader会通过其父类加载器SharedClassLoader去加载java程序类和资源。

9.SharedClassLoader和其上级类加载器都是Java系统默认的委托加载模型，这些类加载器根据自身配置按照其自定义的加载方式再去加载java程序类和资源。

本方法中，自定义的类加载器可以加载指定位置的程序文件，这样就解决了物理层面上文件部署位置方面的对应用服务器的依赖。由此业务系统所使用的第三方程序和自身的核心程序都可以部署放置于应用服务器之外，由自定义的类加载器去加载执行。

由此可知，由于业务流程管理系统的核心业务代码是独立于应用服务器之外的，所以同一套业务流程管理系统的核心业务代码可以同时被多个不同的应用服务器所使用，降低复杂系统的构建难度。

在加载业务流程系统时，不使用Java其自身的类加载器的委托代理加载方式，使用自定义的类加载器，这样就可以按照程序的要求加载应用服务器之外的程序，并按照自定义的加载顺序逻辑，从而在逻辑上也抛弃了对应用服务器的依赖；解决了不同应用服务器和业务流程管理系统的兼容性问题；而且可以实现功能灵活、便于对用户的新需求进行良好设计和可持续支持的底层架构。

本发明还公开了一种基于Java平台的Web业务支持装置，如图2所示，包括：

建立单元201，用于新建自定义类加载器，将自定义类加载器继承指定的父类加载器；

第一加载单元202，用于采用自定义类加载器在预设的存储位置加载java程序类和资源；

第二加载单元203，采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器。

优选的，所述第一加载单元采用自定义类加载器在预设的存储位置加载java程序类和资源，包括：

将新建的自定义类加载器的加载路径设置为自定义的存储路径；

将所述新建的自定义类加载器实例化；

设置所述新建的自定义类加载器的加载行为，令所述自定义类加载器加载在自定义的存储路径上保存的Java程序类和资源；

运行实例化后的新建的自定义类加载器。

优选的，所述第二加载单元采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器，包括：

将所述加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性；

将所述加载Java程序类和资源后的自定义类加载器加载至Java平台内核中，替换Java平台内核中指定的已加载的类加载器。

优选的，所述第一加载单元将自定义类加载器继承的指定的父类加载器，包括：将新建的自定义类加载器继承CustomClassLoader。

优选的，所述第二加载单元将加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性，包括：将加载Java程序类和资源后的自定义类加载器设置为WebappXClassLoader父加载器AppClassLoader的子加载器。

本发明实施例提供的一种基于Java平台的Web业务支持方法和装置，管理人员只需要采用自定义的类加载器加载指定位置的Java类文件，并采用加载Java类文件后的类加载器替换Java平台内核中指定的类加载器，即可采用升级后的Java类文件直接替换原有的Java类文件，从而实现了Web业务系统的动态升级，使应用服务器和业务系统实现分离，避免了和应用服务器之间出现兼容性问题的可能，实现可持续增加新功能；在需求变更的情况下，使维护成本最小化，提高了Web业务系统的性能和服务质量。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (1)

1.一种基于Java平台的Web业务支持方法，其特征在于，包括：

新建自定义类加载器，将自定义类加载器继承指定的父类加载器；

采用自定义类加载器在预设的存储位置加载java程序类和资源；

采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器；

所述自定义类加载器加载具体的程序类和资源时的具体方法为：

S1、业务系统的类加载器加载自定义程序类和资源时，首先在业务流程管理系统自身搜索加载程序和资源；

S2、如果没有找到，业务系统的自定义类加载器才会去通过其上级类加载器去加载程序类和资源，让其上级父类加载器去加载要加载的程序类和资源；

S3、业务系统的自定义类加载器其上级类加载器根据自生配置按照其自定义的加载方式再去加载程序类和资源；

S4、使用自定义的类加载方式，让程序和资源首先在业务流程管理系统内先加载，而不是直接委托上级父类加载的方式；这样就解决了程序在加载时产生的逻辑层面的依赖；

所述采用自定义类加载器在预设的存储位置加载java程序类和资源，包括：

将新建的自定义类加载器的加载路径设置为自定义的存储路径；

将所述新建的自定义类加载器实例化；

设置所述新建的自定义类加载器的加载行为，令所述自定义类加载器加载在自定义的存储路径上保存的Java程序类和资源；

运行实例化后的新建的自定义类加载器；

所述采用加载java程序类和资源后的自定义类加载器替换java平台内核中指定的已加载的类加载器，包括：

将所述加载Java程序类和资源后的自定义类加载器设置为Web应用程序加载类的成员属性；

将所述加载Java程序类和资源后的自定义类加载器加载至Java平台内核中，替换Java平台内核中指定的已加载的类加载器。