软件包依赖关系检查方法及装置与流程

1.本发明涉及大数据技术领域，尤其涉及软件包依赖关系检查方法及装置。


背景技术：

2.本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
3.一般来说，软件包(jar包)是其他人或组织已经写好的一些类文件，然后将这些类文件进行打包。用户可以将这些jar包引入对应的项目中，然后就可以直接使用这些jar包中的类和属性以及方法。而软件包依赖是java项目开发过程中的必需品，当用户的项目中需要用到一些功能时，就会考虑去引用提供这些功能和能力的jar包。
4.而jar包的使用，一般采用人工部署，但因人为部署易出现错漏不当，常会引起生产环境缺少jar包或jar包有误的问题发生。
5.目前，一般借助maven(软件项目管理工具)，对人工部署的软件包，以及软件包间的依赖关系进行检查，但maven仅仅能检查jar包的静态依赖问题。参见图1，在将java程序部署至中间件时，程序一般会与中间件特殊的类加载机制产生关系。如果软件包的部署不当(例如：将oracle驱动包放在了中间件某一个lib目录)；之后在java程序的运行过程中，往往会出现找不到该语言包的情况，在驱动jar包的时则会出现严重失误，仅凭maven工具难以排查出上述问题，会严重影响java程序的正常运行。


技术实现要素：

6.本发明实施例提供一种软件包依赖关系检查方法，用以提升软件包依赖关系检查的准确率，该方法包括：
7.对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；
8.针对软件包依赖关系树中每一存在父节点的子节点：
9.以类加载器体系，加载父节点对应软件包中的第一类文件；
10.以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
11.若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
12.本发明实施例还提供一种软件包依赖关系检查装置，用以提升软件包依赖关系检查的准确率，该装置包括：
13.软件包依赖关系树建立模块，用于对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；
14.子节点遍历模块，用于针对软件包依赖关系树中每一存在父节点的子节点：
15.以类加载器体系，加载父节点对应软件包中的第一类文件；
16.以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
17.若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
18.本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述软件包依赖关系检查方法。
19.本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述软件包依赖关系检查方法的计算机程序。
20.本发明实施例中，对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；针对软件包依赖关系树中每一存在父节点的子节点：以类加载器体系，加载父节点对应软件包中的第一类文件；以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息，与现有技术中借助maven工具实现软件包依赖关系检查的技术方案相比，通过建立软件包依赖关系树，以及检查软件包依赖关系树中节点的类文件，可有效实现对软件包依赖关系的检查，解决了现有技术下通过maven不能精准排查出软件包出现错误的问题，提升了软件包依赖关系检查的准确率。
附图说明
21.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
22.图1为本发明实施例中一种现有技术下检查软件包依赖关系方法的流程示意图；
23.图2为本发明实施例中一种软件包依赖关系检查方法的流程示例图；
24.图3为本发明实施例中一种软件包依赖关系检查方法的具体示例图；
25.图4为本发明实施例中一种软件包依赖关系检查方法的具体示例图；
26.图5为本发明实施例中一种软件包依赖关系检查方法的具体示例图；
27.图6为本发明实施例中一种软件包依赖关系检查装置的结构示意图；
28.图7为本发明实施例中一种软件包依赖关系检查装置的具体示例图。
具体实施方式
29.为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。
30.本发明实施例涉及下列名词，如下进行解释：
31.1)类加载器，classloader，jvm中加载class文件的加载器。
32.2)类加载体系，类加载体系是指多个类加载体系组成的体系，例如：链表结构，树状机构，图状结构；
33.3)双亲委派机制，jdk的类加载体系运行的机制为双亲委派。其他的中间件，如tomcat和websphere有自己的类加载机制；jdk是java语言的软件开发工具包，主要用于移动设备、嵌入式设备上的java应用程序。
34.4)包依赖，包之间的依赖关系，简单些的如a包依赖b包，复杂一些的表现为链条状(a-》b-》c)或树状(a-》b-》c；a-》e-》f)。这里的包依赖并非指maven那种静态的依赖，而是特指在类加载体系中的依赖。
35.当前管理软件包之间复杂依赖关系的工具或方法从用途上来说主要分为两种：基于客户端的包依赖管理工具和基于分发端的包依赖管理工具
36.一般来说，软件包(jar包)是其他人或组织已经写好的一些类文件，然后将这些类文件进行打包。用户可以将这些jar包引入对应的项目中，然后就可以直接使用这些jar包中的类和属性以及方法。而软件包依赖是java项目开发过程中的必需品，当用户的项目中需要用到一些功能时，就会考虑去引用提供这些功能和能力的jar包。
37.而jar包的使用，一般采用人工部署，但因人为部署易出现错漏不当，常会引起生产环境缺少jar包或jar包有误的问题发生。
38.目前，一般借助maven(软件项目管理工具)，对人工部署的软件包，以及软件包间的依赖关系进行检查，但maven仅仅能检查jar包的静态依赖问题。一般借助maven(软件项目管理工具)对人工部署的软件包，以及软件包间的依赖关系进行检查。
39.参见图1，在将java程序部署至中间件时，程序一般会与中间件特殊的类加载机制产生关系。如果软件包的部署不当(例如：将oracle驱动包放在了中间件某一个lib目录)；之后在java程序的运行过程中，往往会出现找不到该语言包的情况，在驱动jar包的时则会出现严重失误，仅凭maven工具难以排查出上述问题，会严重影响java程序的正常运行。
40.除上述之外，一般借助的maven(软件项目管理工具)，在应用系统启动后，还没有业务在上面跑的时候，不可提前探测包依赖的场景，不可提前避免程序运行错误，而容易造成业务来临时的问题突然爆发，尤其是对有时间窗口限制的业务。
41.为了解决上述问题，本发明实施例提供一种软件包依赖关系检查方法，用以提升软件包依赖关系检查的准确率，如图2所示，该方法包括：
42.步骤201：对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；
43.步骤202：针对软件包依赖关系树中每一存在父节点的子节点：
44.以类加载器体系，加载父节点对应软件包中的第一类文件；
45.以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
46.若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
47.本发明实施例中，对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；针对软件包依赖关系树中每一存在父节点的子节点：以类加载器体系，加载父节点对应软件包中的第一类文件；以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息，与现有技术中借助maven工具实现软件包依赖关系检查的技术方案相比，通过建立软件包依赖关系树，以及检查软件包依赖关系树中节点的类文件，可有效实现对软件包依赖关系的检查，解决了现有技术下通过maven不能精准排查出软件包出现错误的问题，提升了软件包依赖关系检查的准确率。
48.具体实施时，首先对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系。
49.实施例中，软件包依赖配置文件可由相关工作人员根据经验进行配置和调整，例如首先需要将依赖关系配置文件完成(如假设a.jar包里的a类文件，依赖b.jar包里的b类文件)。
50.具体实施时，在对软件包依赖配置文件进行解析，建立软件包依赖关系树后，针对软件包依赖关系树中每一存在父节点的子节点：
51.以类加载器体系，加载父节点对应软件包中的第一类文件；
52.以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
53.若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
54.举一实例，以类加载器体系，加载父节点对应软件包中的第一类文件，可以包括：以类加载器体系中的appcl类加载器，去加载父节点对应软件包(a.jar包)中的第一类文件，如a类文件，而实际第一类文件的类加载器为maincl类加载器；之后，以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件，可以包括：以maincl类加载器，去加载子节点对应软件包中的第二类文件，如b类文件。
55.若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息，例如发生：classnotfound或noclassdefineerror的执行通知，则确定该子节点对应软件包(b.jar包)中类文件缺失，缺失类型为缺少该软件包中不含该类文件、或该软件包不存在，则可确定b.jar包缺失。
56.以上述实施例对比现有技术，现有技术下maven的管理的是程序运行之前的包管理；而本发明实施例则是在运行阶段，结合中间件特定的类加载体制下的包依赖检测，两者准确来说并不相同，前者属于“静态”包检测，后者为“动态”包检查，采用的技术原理有本质的区别。
57.具体实施时，本发明实施例提供的一种软件包依赖关系检查方法，还可以包括：若加载出子节点对应软件包中的第二类文件，则确定该子节点对应软件包中类文件无误，并发出该子节点对应的软件包检查通过的通知信息。
58.实施例中，本发明实施例提供的一种软件包依赖关系检查方法，还可以包括：
59.针对软件包依赖关系树中每一存在父节点的子节点：
60.对该子节点对应的软件包、该父节点对应的软件包、和该子节点对应软件包的检查通过与否的检查结果，进行记录。
61.在上述实施例中，通过生成记录文件，可辅助管理人员对上述过程进行随时地调取阅读，有助于管理人员发现上述过程中的漏洞和弊端；同时，工作人员也可通过对记录文件进行调取阅读，实现对上述过程中的数据进行追溯，有助于验证数据的真实性的准确性，提升了上述过程的准确度。
62.具体实施时，本发明实施例提供的一种软件包依赖关系检查方法，还可以包括：针对每一检查未通过的软件包对应的子节点：
63.以更新后的软件包，替换初始软件包；
64.重新以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应的更新后软件包中的第二类文件；
65.若加载出子节点对应的更新后软件包中的第二类文件，则确定该子节点对应的更新后的软件包中类文件无误，并发出该子节点对应的软件包替换成功的通知信息。
66.实施例中，可通过重新以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应的更新后软件包中的第二类文件，并在加载出子节点对应的更新后软件包中的第二类文件时，则确定该子节点对应的更新后的软件包中类文件无误，并发出该子节点对应的软件包替换成功的通知信息，由此可以实现对更新的软件包的核验。
67.下面结合一具体示例，并结合图3和图4，来详细说明本发明实施例提供的方法：
68.一、获取软件包依赖配置文件。
69.以图3为例，1)首先需明确包依赖关系，包依赖关系可以抽象多个树状结构；然后系统启动后，解析依赖关系，然后循环检测依赖关系，最后给出报告。
70.2)该发明实施例也支持依赖的即席检测，即不用预先配置依赖关系，在系统运行过程中由用户(一般为开发人员)发起的临时的依赖检测。
71.参见表1，是设置包依赖配置文件的伪代码。设置包依赖的设置关系，逻辑上是一颗或多颗树关系，配置内容示例如下：
72.表1
[0073][0074][0075]
二、参见图4，建立软件包依赖关系树，即读入依赖配置xml文件，经过解析后，形成依赖树对象。
[0076]
参见图5，上述包依赖关系可以抽象为树结构，依赖配置由一颗到多颗这样的树结构组成。检测时从树的跟节点出发，采用深度遍历的方法，一个一个去检测。
[0077]
三、循环遍历每一子节点对应的软件包，即依赖检测模块，循环依赖树，逐个检查各节点的依赖情况。
[0078]
针对软件包依赖关系树中每一存在父节点的子节点：
[0079]
以类加载器体系，加载父节点对应软件包中的第一类文件；
[0080]
以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
[0081]
若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
[0082]
上述过程的运行基础为包依赖检测核心逻辑，其通过应用的类加载器(例如appcl)加载a类，再获得实际加载a类的类加载器(例如maincl)，然后再用maincl去加载b类，如果发生classnotfound或noclassdefineerror，则表示b.jar包缺失。
[0083]
实现上述过程的伪代码如表2所示。
[0084]
表2
[0085]
[0086][0087]
四、生成子节点的检测结果报告，即结果模块将结果写入文件或存入数据库。
[0088]
针对软件包依赖关系树中每一存在父节点的子节点：
[0089]
对该子节点对应的软件包、该父节点对应的软件包、和该子节点对应软件包的检查通过与否的检查结果，进行记录，如拆分成了两两相连的依赖结果列表，如表3所示。
[0090]
表3
[0091]
引导包被依赖包检测结果ae成功ce成功eg成功ew成功
cf失败
[0092]
当然，可以理解的是，上述详细流程还可以有其他变化例，相关变化例均应落入本发明的保护范围。
[0093]
本发明实施例中，对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；针对软件包依赖关系树中每一存在父节点的子节点：以类加载器体系，加载父节点对应软件包中的第一类文件；以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息，与现有技术中借助maven工具实现软件包依赖关系检查的技术方案相比，通过建立软件包依赖关系树，以及检查软件包依赖关系树中节点的类文件，可有效实现对软件包依赖关系的检查，解决了现有技术下通过maven不能精准排查出软件包出现错误的问题，提升了软件包依赖关系检查的准确率。
[0094]
如上述，本发明通过技术手段规避了因人为部署的不当，而导致的生产环境缺少jar包问题或故障。将常用的包依赖问题(oracle的语言包，rocketmq包等)，固化成专门的xml文件，并且在系统启动后对外营业之前，自动执行包依赖检测，并生成检测结果。避免了缺包(部署)导致的系统严重问题。尤其是这类问题不打印警告信息，不抛异常的情况下，该问题排查起来异常困难。本发明进一步加固了系统的生产安全。
[0095]
本发明实施例中还提供了一种软件包依赖关系检查装置，如下面的实施例所述。由于该装置解决问题的原理与软件包依赖关系检查方法相似，因此该装置的实施可以参见软件包依赖关系检查方法的实施，重复之处不再赘述。
[0096]
本发明实施例还提供一种软件包依赖关系检查装置，用以提升软件包依赖关系检查的准确率，如图6所示，该装置包括：
[0097]
软件包依赖关系树建立模块601，用于对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；
[0098]
子节点遍历模块602，用于针对软件包依赖关系树中每一存在父节点的子节点：
[0099]
以类加载器体系，加载父节点对应软件包中的第一类文件；
[0100]
以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；
[0101]
若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息。
[0102]
在一个实施例中，还可以包括：
[0103]
第二类文件加载模块，用于若加载出子节点对应软件包中的第二类文件，则确定该子节点对应软件包中类文件无误，并发出该子节点对应的软件包检查通过的通知信息。
[0104]
在一个实施例中，还可以包括：
[0105]
记录模块，用于针对软件包依赖关系树中每一存在父节点的子节点：
[0106]
对该子节点对应的软件包、该父节点对应的软件包、和该子节点对应软件包的检查通过与否的检查结果，进行记录。
[0107]
在一个实施例中，还可以包括：
[0108]
软件包替换模块，用于针对每一检查未通过的软件包对应的子节点：
[0109]
以更新后的软件包，替换初始软件包；
[0110]
重新以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应的更新后软件包中的第二类文件；
[0111]
若加载出子节点对应的更新后软件包中的第二类文件，则确定该子节点对应的更新后的软件包中类文件无误，并发出该子节点对应的软件包替换成功的通知信息。
[0112]
下面给出一个具体实施例，来说明本发明的装置的具体应用，如图7所示，该实施例，可以包括：
[0113]
依赖关系配置模块：设置包依赖的设置关系，逻辑上是一颗或多颗树关系；
[0114]
包检测模块：接收配置模块的xml文件，解析并进行检测，最后将结果写入检测结果模块；
[0115]
检测结果模块：检测结果可以落地为文件，也可以写入数据库等，可以自行扩展。
[0116]
当然，可以理解的是，上述详细流程还可以有其他变化例，相关变化例均应落入本发明的保护范围。
[0117]
本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述软件包依赖关系检查方法。
[0118]
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述软件包依赖关系检查方法的计算机程序。
[0119]
本发明实施例中，对软件包依赖配置文件进行解析，建立软件包依赖关系树；所述软件包依赖配置文件用于描述不同软件包之间的依赖关系；所述软件包依赖关系树以软件包为节点、以软件包间的依赖关系为节点间的连接关系；针对软件包依赖关系树中每一存在父节点的子节点：以类加载器体系，加载父节点对应软件包中的第一类文件；以类加载器体系中加载所述第一类文件的类加载器，加载子节点对应软件包中的第二类文件；若无法加载所述第二类文件，则确定该子节点对应软件包中类文件缺失，并发出该子节点对应的软件包检查未通过的告警信息，与现有技术中借助maven工具实现软件包依赖关系检查的技术方案相比，通过建立软件包依赖关系树，以及检查软件包依赖关系树中节点的类文件，可有效实现对软件包依赖关系的检查，解决了现有技术下通过maven不能精准排查出软件包出现错误的问题，提升了软件包依赖关系检查的准确率。
[0120]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0121]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产
生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0122]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0123]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0124]
以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。