随笔-11  评论-10  文章-8  trackbacks-0

个人心得

这段时间一直在修改ECperf,主要心得都是EJB应用方面的,对EJB部署的复杂和调试的痛苦深有感触,其中主要原因可能是我对EJB不太熟悉,没有用EJB开发应用的经验,以下的几点心得在熟手看来可能是理所当然的,但却折磨我了好久。

1.              EJB部署

部署应用实际上就是将应用安装到应用服务器上,按书上部署Hell Word时没有遇到丝毫困难,但在部署ECperf时却冒出了一堆问题。其中困扰我最久的就是EJB互相引用的问题,实际上只需要将所有的引用关系和JNDI名写入sun-ejb-jar.xml就可以了(借助sun的部署工具很容易实现,不同的应用服务器会有不同的文件名如,格式可能也会不同)。在ejb-jar.xml中,每个EJB必须申明自己引用的EJB的类型,home接口,remote接口,和ejb的引用名,引用名不需要与JNDI名相同,在sun-ejb-jar.xml要申明ejb引用名对应的JNDI名。DataSource也需要如此设置,对于env-entry好像不需要在sun-ejb-jar.xml中申明。由此可以看出应用服务器对EJB所能访问的资源做了严格的控制,而ejb不是直接引用JNDI名,也为ejb应用提供了一定的灵活性。

2.              EJB调用

在同一容器调用EJB和远程调用EJB有很大不同。同一容器中调用者与被调用者有相同的Context,因此不需要额外设置,而在远程调用需要指定java.naming.factory.initialjava.naming.provider.url,另外还要部署时产生的client jar

在调用PortableRemoteObject.narrow()得到home接口时抛出java.lang.ClassCastException

一般将client jar 放到 classpath中就可以解决,这里主要用到的是remote接口和home接口的stub。如果不将client jar 放到classpath中也可以得到home的接口,但由于使用了不同的classload,在用PortableRemoteObject.narrow()进行转型被视为不同的类而转型失败,我在用sun的部署工具得到的 client jar中竟然没有stub(可能是部署文件的问题),所以远程调用始终不成功。

3.              下一步学习的方向

继续研究远程对象是如何返回的

Classload 是如何工作的

JDBC中关于分布式事务的处理方式

容器处理事务的规则

posted on 2005-08-23 23:04 JBahamut 阅读(1713) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航:
 
<2005年8月>
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

常用链接

留言簿(1)

随笔档案

文章档案

收藏夹

link

搜索

  •  

最新评论

阅读排行榜

评论排行榜