万字+28张图带你探秘小而美的规则引擎框架LiteFlow（五）

分割完之后，就会遍历每个路径，然后判断文件的格式，比如xml、json、yaml，然后根据文件格式找到对应的FlowParser。

随后根据liteflowConfig.isSupportMultipleType()判断是不是支持多类型的，什么叫多类型，就是指规则文件配置了多个并且文件的格式不同，如果支持的话，需要每个规则文件单独去解析，如果不支持，那就说明文件的格式一定是相同的，相同可以在最后统一解析，解析是通过调用FlowParser的parseMain来解析的。

剖析完之后整个init方法就会结束，然后继续调用DataBus的init方法，其实就是初始化DataBus。

到这其实构建FlowExecutor就完成了，从上面我们得出一个结论，那就是在构造FlowExecutor的时候会通过FlowParser的parseMain来处理对应规则文件的路径，所以接下来我们分析一下这个FlowParser是如何解析xml的，并且解析了之后干了什么。

2）FlowParser规则解析流程

接下来我们进入FlowParser来看看一个是如何解析规则的。

以本文的例子为例，因为是配置本地的xml文件，找到的FlowParser的实现是LocalXmlFlowParser。

接下会调用parseMain方法，parseMain的方法的实现很简单，首先根据PathContentParserHolder拿到一个PathContentParser来解析路径，对上面案例来说，就是flow.xml路径，拿到路径对应文件的内容，其实就是拿到了flow.xml内容。然后调用父类的parse方法来解析xml的内容，所以parse方法才是解析xml的核心方法。

这里有个细节说一下，PathContentParserHolder其实内部使用了Java的SPI机制来加载PathContentParser的实现，然后解析路径，拿到内容，在Spring环境中默认基于Spring的实现的优先级高点，但是不论是怎么实现，作用都是一样的，那就是拿到路径对应的xml文件的内容，这里就不继续研究PathContentParser是如何加载文件的源码了。

其实不光是PathContentParser，LiteFlow内部使用了很多SPI机制，但是基本上整合Spring的实现的优先级都高于框架本身的实现。

接下来我们就来看一下LocalXmlFlowParser父类中的parse方法的实现。

首先遍历每个文件中的内容，然后转成Document，Document其实是dom4j的包，其实就是将xml转成Java对象，这样可以通过Java中的方法来获取xml中每个标签的数据。

将文件都转换成Document之后，调用parseDocument方法。

首先调用了ContextCmpInitHolder.loadContextCmpInit().initCmp() ，这行代码也是通过SPI机制来加载ContextCmpInit，调用initCmp方法。框架本身对于initCmp的实现是空实现，但是在Spring环境中，主要是用来整合Spring中的Node节点的，将Node节点添加到FlowBus中，这也是为什么在Spring环境中的那个案例中不需要在xml文件中配置<nodes/>的原因，因为LiteFlow会自动识别这些Node节点的Spring Bean。至于怎么整合Spring的，有兴趣的同学可以看一下ComponentScanner类的实现，主要在Bean初始化之后进行判断的，这里画一张图来总结一下initCmp方法的作用。

至于为什么需要先将Spring中的Node节点添加到FlowBus，其实很简单，主要是因为构建Chain是需要Node，需要保证构建Chain之前，Spring中的Node节点都已经添加到了FlowBus中。

文章转自公众号：三友的java日记