WebOTX中的JNDI实践

WebOTX是NEC公司的Application Server产品.我使用的版本是5.3.它的Web Container是Tomcat4.0.在WebOTX中配置JNDI数据源曾经颇费周折.下面就简单介绍其中的一个方面.
一般来说,只要在服务器端进行正确的配置,从JNDI中拿到的对象是不会出现问题的.但是,如果服务器本身就是有缺失的,如它在启动的过程中少装载一个JAR包,或者说服务器自身环境配置就存在问题,那就有可能出现意想不到的情况.

 

在服务器中配置 JNDI数据源 (javax.sql.DataSource)时 ,不同的服务器中 lookup得到的 Object是不同的 .在 Tomcat5中得到的是 org.apache.commons.dbcp.BasicDataSource类 ,在 Jboss3.2中得到的是 org.jboss.resource.adapter.jdbc.WrapperDataSource类 ,在 WebOTX5.3中得到的是 jp.co.nec. WebOTX.WODataSource类 .所有的这些类都实现了 javax.sql.DataSource接口 ,所以我们才可以 Cast这个 Object为 javax.sql.DataSource.

但是 ,如果服务器启动时 ,它的类装载系统没有导入包含这些类的 JAR包 ,那么 ,不同的服务器就会出不同的错误 .

对于 Tomcat,错误发生在实际动作时 ,即 lookup方法被调用的地方 .它会出一个 ClassNotFoundException异常 .

对于 JBoss,错误发生在服务器启动时 (错误的原因就是类缺失 ).也就是说 ,JBoss中的对象 Bind动作是在 服务器启动时完成的 .如果在发生服务器启动错误的情况下仍然进行 lookup动作 ,就会出现 javax.naming.NameNotFoundException异常 .

对于 WebOTX,错误也是发生在实际动作时 .但是它和 Tomcat不同的是 ,它出一个 ClassCastException异常 .这个异常说明不是类装载器的问题 ,而是的确 lookup到了一个 Object,但这个 Object不是 javax.sql.DataSource接口 .就像前面所说的 ,得不到 DataSource的真正原因就是由于 类路径 (是指类装载器委托模型中的类 ,它并不等同于 CLASSPATH,相反 CLASSPATH只是其中的一部分 )不全 ,这说明在 WebOTX中 lookup时抛出的 ClassCastException异常掩盖了原始的异常信息 .掩盖的根本原因是 ,原始的异常信息被 WebOTX服务器处理了 ,并且处理后并没有把异常信息告诉它的客户程序 .

Java 异常处理的一个规则就是不要遮蔽异常 . 因为一旦出现这种情况 , 而客户程序又非常想知道错误原因 , 那么就可能丢失问题真正原因的线索 .

这个错误也提供了一个 WebOTX5.3 不成熟的证据 .

出现这种情况 ,就只能从 lookup得到的 Object来查找线索了 .结果发现 Object是 javax.naming.Reference对象 , 这就说明了错误是由 类路径不全造成的 .但是又暴露了 WebOTX的另外一个问题 ---类装载器 .

一个设计良好的应用框架系统 , 是有必要建立自己的类装载系统的 , 而不能过分依赖系统 CLASSPATH 变量 . 例如 ,Tomcat 有自己的 类装载机制 ,JBoss 也是 .Eclipse 则干脆不用系统 CLASSPATH 变量 . 具体信息请参照它们的文档 .

如果过分依赖 CLASSPATH,就会有一个副作用 ,就是造成自身系统的不稳定 .因为 CLASSPATH是开放的 ,无法确保其它应用对它的修改不会对自身系统产生负面影响 .

WebOTX就是一例.它的Web Container就是Tomcat,除了把一些JAR包放在了Tomcat认可的目录下外,它把有些JAR包就设置到了系统CLASSPATH变量下.造成的问题就是,连启动它的Web Container都成了一件困难的事情.这又是一个证据.