部署Pentaho BI服务器到独立Tomcat所碰到的问题总结

桀昊j

　　研究Pentaho快到一个星期了，期间遇到各式各样的问题，趁着国庆长假，静下心来总结下心得，方便自己今后继续对Pentaho的研究和运用，也希望该博文能够给正在研究和打算研究Pentaho的同志们一点帮助吧！首先声明下，该博文只是针对Pentaho初期研究阶段过程中自己的体会，并没有涉及太多的关于Pentaho内部的运行机制，从严格意义上来说只是针对Pentaho资源库数据库的迁移部署和执行自定义Action Sequence过程所遇到的“疑难杂症”的浅谈而已。如果大家只是针对Pentaho BI服务器内置的资源库数据库的迁移方法有兴趣，不妨参考下前一期的博文——《pentaho——如何将Pentaho BI服务器的资料库迁移到MySQL数据库》，在这里大家会对Pentaho BI资源库的迁移步骤有个初步的理解。
　　在这里主要打算谈谈将Pentaho项目部署到独立（第三方Tomcat）web服务器过程中数据库迁移过程中与《pentaho——如何将Pentaho BI服务器的资料库迁移到MySQL数据库》一文中所遇到的不一样的问题的探讨以及对执行自定义Action Sequence过程所遇到的“疑难杂症”的解决之道！
　　首先，之所以将Pentaho项目独立部署主要是方便对Pentaho 项目源码研究以及其内部运行机制的探讨。这里关键的就是Pentaho项目中所用到的资源库数据库了。Pentaho BI服务器自带的数据库为内存数据库——HSQLDB，每次启动Pentaho之前必须先将HSQLDB数据库启动，在内存中装载好所必须的资源库。而这样所带来的不爽之处便是一直得运行该内存数据库，否则项目运行过程中就会出错。这样带给我们的思考便是将Pentaho运行过程中所需要用到的资源库持久化到类似MySQL数据库中，方便我们之后对Pentaho运行原理的探究。其实这个过程中主要是针对如下配置文件的修改：applicationContext-spring-security-jdbc.xml；applicationContext-spring-security-hibernate.properties；hibernate-settings.xml；mysql5.hibernate.cfg.xml以及对\META-INF\context.xml文件的修改，而针对以上所有配置文件的详细修改请查看上篇博文相应的做法（《pentaho——如何将Pentaho BI服务器的资料库迁移到MySQL数据库》）。在这里我主要谈的是，即便是完全按照上文的配置方案来配置，在启动Tomcat服务器是仍然会出错：

　　“ERROR [Logger] misc-org.pentaho.platform.scheduler.QuartzSystemListener: QuartzSystemListener.ERROR_0001 - 调度程序在启动时没有被正确初始化
org.quartz.SchedulerConfigException: DataSource name not set.”，百思不得其解，按理说针对MySQL数据库的相关配置都已妥当，而且在Pentaho BI服务器的内置Tomcat服务器中也是运行正常。推理得出，这不应该属于MySQL配置上的问题，最终只好针对出错信息，通过配置文件systemListeners.xml修改为在启动Pentaho时不加载QuartzSystemListener类，即：
  
　　这样就能正常启动Pentaho BI服务器了：

　　只是这样做的后果便是没有了针对Quartz组件的监听作用了。但是这是自己研究几日来的所得出的一个不得已而为之的结局方案，如果哪位同学有更好的解决之道还请在留言中不吝赐教。经过上面的步骤的处理，我们便可以不必再启动内存数据HSQLDB就可直接在启动完相应web服务器之后享受Pentaho带来我们的服务了。
　　接下便是对自定义Action Sequence的执行问题了。在这里我们省去对Action Sequence的定义以及其对Pentaho的作用的探讨，主要针对自己在执行自定义Action Sequence过程中所遇到的问题。Pentaho在执行某一Action Sequence时都是首先通过配置文件：pentahoObjects.spring.xml中定义好的类org.pentaho.platform.repository.solution.filebased.FileBasedSolutionRepository或者org.pentaho.platform.repository.solution.dbbased.DbBasedSolutionRepository在相应文件或者数据库对应表（hibernate\pro-files表）中查询获得对应的Action Sequence定义再加载到内存中完成对应的动作。如是对应前者，系统会从pentaho-solutions文件夹中搜寻相关的Action Sequence文件，而后者这是通过查询数据库Hibernate中的pro-files表（该表记录了pentaho-solutions中除system文件夹中的所有文件和文件夹）中的相应记录来获得相应Action Sequence定义。在研究Pentaho阶段建议使用前者，方便调试，效率更高。通过修改文件pentahoObjects.spring.xml对应的条目即可：
  
　　当然也可不修改。系统默认情况下是首先查询对应数据库，若有修改再扫描相应文件获得对应Action Sequence定义。在这里，我需要着重强调下，如果选择后者，在调试自定义Action Sequence时，三个主要参数：solution、path及action的键值对的输入一定要与实际路径相一致，因为匹配数据库表的记录时大小写敏感，否则就会出现异常，执行不成功！
　　以上便为近期对pentaho的初步研究，其中可能会有所遗漏或者错误的地方。希望在之后的深入研究过程中能够完善对Pentaho各方面细节的理解并写出博文与各位同学共同学习进步！祝各位国庆快乐！^_^