涂0实验室

在jboss下，如果包含ejb的jar，和要通过local接口访问ejb的war不被打包成一个ear来部署，会遇到问题。如果你的war中包含了ejb3的local接口的class，那么war在通过jndi取得ejb的引用试图将其转化成接口类型时会抛ClassCastException。而如果war中不包含local接口的class，则会抛class not found的异常。这都是由讨厌的classloader问题导致的。每个放到jboss的deploy目录里的部署单元都有自己的独立的classloader树，这两棵树在jvm的classloader里是平级的。如果war和ejb jar里都包含了某个ejb的local接口的class时，那么同一个类就分别存在于两棵classloader树中。通过jndi取得的引用的类型是ejb jar中的local接口的类型，将其转化成war里的那个local接口类型时就出错了，因为它们不是同一个类。而classloader是不能访问同级的其他的classloader下的类的，所以如果war里不包含接口的class，有会因找不到class而出错。

这种时候就是使用ear的时候，位于同一个ear里ejb jar的classloader是war的classloader的父classloader。这样，只需要部署一份接口类，war也能访问到它，因为子classloader能访问父classloader载入的类。

用普通的java bean 做conversation scope内的组件会有这么大的性能问题，那么用ejb会怎么样呢？我今天特意做了一个测试，还是在那台开发机上，还是用那个 supplierSearchAction, 所做的变更，只是把SupplierSearchAction由普通的java bean变成了ejb。我在用ejb，普通conversation scope的java bean, 和page scope的 java bean分别测试了十次，最后的统计结果显示在conversation内ejb的性能还是要高于普通java bean的。conversation pojo 用时 5秒, conversation ejb 用时 3 秒, page pojo 用时 1 秒。在conversation内，ejb比pojo快40%, 而page scope内的pojo比前两者分别快 5 倍和 3倍。虽然还不清楚，为什么在conversation内ejb会比pojo性能要好，但在这一前提下，我们知道，如果非要写conversation内的组件，ejb将是更好的选择。