花费了两天时间,发现tomcat 4.1.27与tomcat4.1.24区别

03-10-31 banq

这个区别是从JBoss 3.22RC和JBoss 3.22上发现的。

同样的包含Struts的ear发布包,在JBoss 3.22RC上运行正常,而在JBoss 3.22下运行出错,在排除了classloader等容器原因之外,发现是Web容器问题,将ear分解成war在这两个版本中测试,果然。

JBoss 3.22RC使用的是tomcat 4.1.24版本,而Jboss 3.2.2使用的是tomcat 4.1.27版本,后者在re-deploy Web包时,调用同样的程序,会报校验错误,同样的程序拷贝到Tomcat 4.1.24下运行正常。

开源代码好是好,陷阱可真不少 !

bullboss
2003-11-01 07:01

?? 一团雾水. 要说什么?

banq
2003-11-01 14:14

JBoss 3.22RC和JBoss 3.22在classloader机制上有区别,这给部署程序带来不方便。

banq
2003-11-01 14:47

例如:我的应用程序有很多可重用组件,那么多个应用程序需要这些重用组件时,在容器class loader时就有问题,应用程序是基于组件的、共存但是独立的、可重新加载的。

再可重新加载这方面,就是同一容器的不同版本也不一样。

应用程序之间的相关性:

一般来说,应用程序之间的相关性应该减至最小,J2EE 1.3中没有满足这一点的可用机制。需要相关性的时候,可以从两个方面考虑,这取决于你希望共享代码对所有应用程序是可见的,还是只对某些应用程序可见:

第一:对所有应用程序。为了使共享代码对所有应用程序是可见的,需要把这些共享代码放入JRE扩展目录(当启用服务器时,通过-classpath包括它们),或者使用供应商特定的机制。在这一级别上修改代码可能需要重启服务器。

第二:对某些应用程序。 要使共享代码只对某些应用程序是可见的,需要在每个应用程序里复制这些共享代码,或者使用供应商特定的配置选项。这儿需要考虑的一个重要事项是:一个共享类的一个对象是否必须对这些应用程序是可见的。如果是,则复制这些共享程序是无效的,因为该类被复制,而如前所述,虚拟机认为它们是不同的类。

选择“对某些应用程序是可见的”是很不理想的。因为复制增加了风险和内存占用,还会导致版本问题;而依赖于供应商特定的机制则降低了可移植性。在容器级别上部署是一个选择,但可能导致这些共享代码可见度过高,还可能会限制应用程序重新加载。

我的应用程序是选择了“对某些应用程序是可见的”,所以在JBoss 3.22和jBoss 3.2.2RC2部署时出现不同的结果。

banq
2003-11-01 15:22

我想说的是:J2EE中,类加载机制是非常复杂而且耗时的,不同容器的实现机制不一样,必须研究透彻,摘引下面一句话:

"如果你曾经花费数小时的时间调试诸如ClassNotFoundException、 NoClassDefFoundError 或者 ClassCastException的这样一些异常,那么肯定你不是唯一这样做的人。"

4Go 1 2 3 4 下一页