插件启动顺序控制

在使用obr的时候，用deploy -s命令部署和启动插件，如果一个插件有依赖的插件，felix可以自动计算出来并部署启动所依赖的插件，这样保证了被依赖的启动，由于使用了ipojo，可以自动注入依赖的服务，并启动那些一开始依赖不满足而未启动的pojo，这样就可以在不用特别关注插件启动顺序的情况下，确保所有插件正确启动了。

但是在开发groovy插件时，碰到一个情况，就是groovy插件pom中依赖sqlapi，但是实际上需要mybatis提供的sqlapi服务和configcenter提供的ccapi服务，而groovy插件由于是用groovy脚本编写的，没法直接使用ipojo，这样就会出现启动groovy插件时可能存在需要的mybatis和configcenter插件还没启动的情况，就导致了groovy插件启动失败。要正确启动groovy插件，必须确保先启动mybatis和configcenter插件，如何确保插件之间的启动顺序就成了一个重要的问题。

直接在groovy插件中依赖mybatis和configcenter插件并不能保证启动顺序。

手工输入deploy -s命令，依次启动插件，可以保证顺序，但是如果直接这样写到tsl脚本里面，执行起来却报错，第二个deploy没法正常执行。

用install或者start命令是可以在tsl中写多个并按照顺序的，但是问题在于start需要使用id，在tsl中直接写id比较死。

最后找到一种方法可以比较好的控制顺序，就是通过指定bundlelevel和frameworklevel，例子如下：

bundlelevel -i 2

deploy -s com.ailk.common.log4j com.ailk.common.configcenter com.ailk.common.mybatis

bundlelevel -i 3

deploy -s com.ailk.common.groovy

frameworklevel 3

 

• 系统默认bundlelevel和frameworklevel是1，启动felix时，默认启动的bundle的level都设为1，并且level1的bundle都可以启动
• 然后在tsl中设定当前bundlelevel为2，那么下面deploy的所有bundle的level都设为了2，但是由于frameworklevel没变还是1，level为2的bundle并未真正启动
• 再用同意的方法把部署需要最后启动的bundle，level设为3
• 最后把frameworklevel设为3时，系统首先启动level2的bundle，然后才是level3的，这样就确保了bundle的启动顺序