cuiyi's blog（崔毅 crazycy）

robbin在其文 http://www.javaeye.com/topic/11 中如下描述

Java本身是一种设计的非常简单，非常精巧的语言，所以Java背后的原理也很简单，归结起来就是两点：

1、JVM的内存管理

     理解了这一点，所有和对象相关的问题统统都能解决

2、JVM Class Loader

     理解了这一点，所有和Java相关的配置问题，包括各种App Server的配置，应用的发布问题统统都能解决

如果在App Class Loader级别配置，是全局可见的。
如果打包在EJB里面，那么就不会影响到Web Application，反之亦然，如果你在WEB-INF下面放置Hibernate，也不会影响到EJB。
放在EJB Class Loader或者放在Web App Class Loader级别主要就是在局部范围内有效，不影响到其它的应用。
（＃me：这里是说ClassLoader都有一个加载边界＃）

试想，如果在一个Weblogic上面配置多个虚拟域，你使用www.bruce.com域名，开发你的网站，我使用 www.fankai.com开发我的网站，那么当然不希望我们的Hibernate相互干扰，所以就可以放在 EJB Class Loader级别来配置Hibernate。

进一步阐述一下EJB Class Loader的问题：

先再次强调一下，Hibernate和EJB，和App Server不存在兼容性问题，他们本来就是不相关的东西，就好像JDBC，相信没有人会认为JDBC和EJB不兼容吧，Hibernate也是一样，它 只和JDBC驱动，和数据库有兼容性问题，而和EJB，和App Server完全是不搭界的两回事。凡是认为Hibernate和EJB不兼容的人，其实是都是因为对EJB学习的不到家，把责任推到Hibernate 身上了。

我前面的帖子提到过Class Loader的层次，这里不重复了，总之我们先来看看Class Loader的作用范围：
（＃me: BootStrap Class Loader会加载ExtClassLoader, 并设置其parent为null
              然后BootStrap Class Loader会加载AppClassLoader,并设置其parent为ExtClassLoader
              然后ExtClassLoader加载，AppClassLoader再加载＃）

在一个特定的App Server上，Class Loader会继续向下继承，继承的层次会根据不同的App Server有所不同，但是肯定不会变的就是：

Web App Class Loader很好理解，大家毕竟用的很多，App Server上的一个Web Application会创建一个Web App Class Loader的实例去负责load class，所以如果你想让Hibernate只在这个Web Application内生效，把它放到WEB-INF"lib下去就好了。

如果你把Hibernate放到了CLASSPATH变量指定的路径下，而你在WEB-INF"lib也放了一份，那么Web App Class Loader由于load范围所限，它会首先找到WEB-INF"lib下的那份Hibernate，按照它的配置来初始化Hibernate。

如果你把Hibernate放到了CLASSPATH变量指定的路径下，但你在WEB-INF"lib什么都没有放，那么Web App Class Loader由于load范围所限，它根本什么都找不到，于是它把load Hibernate的责任交给上一级的Class Loader，这样直到App Class Loader，它找到了Hibernate，按照它的配置来初始化Hibernate。

EJB Class Loader稍微复杂一点，不那么容易理解。App Server会针对每一个EJB包文件创建一个EJB Class Loader的实例，例如：

当你把这两个jar发布到App Server上以后，会创建两个EJB Class Loader的实例，分别去load这两个EJB包，比如说：
那么CLEJB_Robbin的load范围就仅仅限于HelloRobbin.jar之内，它load不到HelloRobbin.jar之外的任何文件，当然它也load不到HelloBruce.jar。

说到这里，我相信大家应该已经明白为什么EJB规范不允许EJB有IO操作了吧？因为EJB Class Loader根本找不到jar包之外的文件！！！
（＃me:这里是我疑问最大的地方，也是测试验证的地方＃）

如果现在你想实现HelloRobbin.jar和HelloBruce.jar的互相调用，那么该怎么办？他们使用了不同的EJB Class Loader，相互之间是找不到对方的。解决办法就是使用EAR。

现在假设HelloRobbin.jar和HelloBruce.jar都使用了Hibernate，看看该怎么打包和发布：


除此之外，按照EJB规范要求，HelloRobbin.jar和HelloBruce.jar还必须指出调用jar包之外的类库的名称，这需要在jar包的manifest文件中定义：

MANIFEST.MF中必须包括如下一行：

这样就OK了，当把HelloEJB.ear发布到App Server上以后，App Server创建一个EJB Class Loader实例load EAR包里面的EJB，再根据EJB的jar包里面的MANIFEST.MF指出的Class-Path去寻找相应的jar包之外的类库。

所以一个EAR包有点类似一个Web Application，EJB Class Loader的load范围也就是EAR范围之内，它load不到EAR之外的文件。除非把Hibernate定义到CLASSPATH指定的路径下，在 这种情况下，EJB Class Loader找不到Hibernate，只能交给上一级的Class Loader，最后由App Class Loader找到Hibernate，进行初始化。

没有写完，继续说...

由于EAR这样load Class规则，假设Robbin和Bruce都在同一个Weblogic上运行自己的网站，而我们都不希望自己的程序里面的Hibernate配置被对方的搞乱掉，那么我们就可以这样来做：

这样在同一个App Server上运行，就可以互相不干扰。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
至此，这个是引文，外加了部分个人的解释。
其中针对如下的话：
我感觉很疑惑，同时EJB规范似乎有大概如下描述：
EJB模型不推荐或者禁止在EJB组件中读取文件....

为什么不允许读取文件呢？是否真的找不到呢？
我采用了两种方式：
结果得到如下结论：
方式一 如果采用getResourceAsStream的方式，无法访问ear包之外的资源
方式一采用绝对路径的文件方式，貌似返回是null（记录有点模糊了）
方式二采用绝对路径，绝对没有问题

我现在想，并不是真的不能访问外部资源，而是其设计就是为了把classloaser的界限限制在jar包内或者ear内，而不相互干扰，因而在其规范中就是禁止或者不推荐读取文件的方式了。