kapok

http://forum.javaeye.com/viewtopic.php?t=11
Java本身是一種設計的非常簡單，非常精巧的語言，所以Java背后的原理也很簡單，歸結起來就是兩點：

1、JVM的內存管理

理解了這一點，所有和對象相關的問題統統都能解決

2、JVM Class Loader

理解了這一點，所有和Java相關的配置問題，包括各種App Server的配置，應用的發布問題統統都能解決

App Class Loader
|----- EJB Class Loader
|----- Web App Class Loader

如果在App Class Loader級別配置，是全局可見的。如果打包在EJB里面，那么就不會影響到Web Application，反之亦然，如果你在WEB-INF下面放置Hibernate，也不會影響到EJB。放在EJB Class Loader或者放在Web App Class Loader級別主要就是在局部范圍內有效，不影響到其它的應用。

試想，如果在一個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的作用范圍：

BootStrap Class Loader:

load JRE\lib\rt.jar, sunrsasign.jar, charsets.jar, jce.jar, jsse.jar, plugin.jar

Ext Class Loader:

load JRE\lib\ext目錄下的庫文件, load JRE\classes目錄下的類

App Class Loader:

load CLASSPATH變量指定路徑下的類

以上的load路徑都是寫死在JVM的C++源代碼里面的，不能改變，詳細請見王森的《Java深度歷險》

在一個特定的App Server上，Class Loader會繼續向下繼承，繼承的層次會根據不同的App Server有所不同，但是肯定不會變的就是：

EJB Class Loader:

繼承自App Class Loader，繼承層次根據App Server有所不同，一個EJB Class Loader它的load Class的范圍僅限于JAR或者EAR范圍之內。

Web App Class Loader:

繼承自App Class Loader，繼承層次根據App Server有所不同，一個Web App Class Loader:它的load Class的范圍在 WEB-INF\lib下的庫文件和WEB-INF\classes目錄下的class文件。

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的實例，例如：

HelloRobbin.jar
HelloBruce.jar

當你把這兩個jar發布到App Server上以后，會創建兩個EJB Class Loader的實例，分別去load這兩個EJB包，比如說：

CLEJB_Robbin是load HelloRobbin.jar的
CLEJB_Bruce是load HelloBruce.jar的

那么CLEJB_Robbin的load范圍就僅僅限于HelloRobbin.jar之內，它load不到HelloRobbin.jar之外的任何文件，當然它也load不到HelloBruce.jar。

說到這里，我相信大家應該已經明白為什么EJB規范不允許EJB有IO操作了吧？因為EJB Class Loader根本找不到jar包之外的文件！！！

如果現在你想實現HelloRobbin.jar和HelloBruce.jar的互相調用，那么該怎么辦？他們使用了不同的EJB Class Loader，相互之間是找不到對方的。解決辦法就是使用EAR。

現在假設HelloRobbin.jar和HelloBruce.jar都使用了Hibernate，看看該怎么打包和發布：

HelloEJB.ear
|------ HelloRobbin.jar
|------ HelloBruce.jar
|------ Hibernate2.jar
|------ pojo.jar (定義所有的持久對象和hbm文件的jar包)
|------ cglib-asm.jar
|------ commons-beanutils.jar
|------ commons-collections.jar
|------ commons-lang.jar
|------ commons-logging.jar
|------ dom4j.jar
|------ odmg.jar
|------ log4j.jar
|------ jcs.jar
|------ hibernate.properties
|------ log4j.properties
|------ cache.ccf
|------ META-INF\application.xml (J2EE規范的要求，定義EAR包里面包括了哪幾個EJB)

除此之外，按照EJB規范要求，HelloRobbin.jar和HelloBruce.jar還必須指出調用jar包之外的類庫的名稱，這需要在jar包的manifest文件中定義：

HelloRobbin.jar
|------ META-INF\MANIFEST.MF

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

Class-Path: log4j.jar hibernate2.jar cglib-asm.jar commons-beanutils.jar commons-collections.jar commons-lang.jar
commons-logging.jar dom4j.jar jcs.jar odmg.jar jcs.jar pojo.jar

這樣就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配置被對方的搞亂掉，那么我們就可以這樣來做：

Robbin's Website:

Robbin.ear
|-------- robbin.war (把Web Application打包)
|-------- robbin.jar (把開發的EJB打包）
|-------- Hibernate2.jar
..........................
|-------- META-INF\application.xml

Bruce's Website:

Bruce.ear
|-------- bruce.war (把Web Application打包)
|-------- bruce.jar (把開發的EJB打包）
|-------- Hibernate2.jar
..........................
|-------- META-INF\application.xml

這樣在同一個App Server上運行，就可以互相不干擾。

A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class. Given the name of a class, a class loader should attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a "class file" of that name from a file system.

Every Class object contains a reference to the ClassLoader that defined it.

Class objects for array classes are not created by class loaders, but are created automatically as required by the Java runtime. The class loader for an array class, as returned by Class.getClassLoader() is the same as the class loader for its element type; if the element type is a primitive type, then the array class has no class loader.

Applications implement subclasses of ClassLoader in order to extend the manner in which the Java virtual machine dynamically loads classes.

Class loaders may typically be used by security managers to indicate security domains.

The ClassLoader class uses a delegation model to search for classes and resources. Each instance of ClassLoader has an associated parent class loader. When requested to find a class or resource, a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. The virtual machine's built-in class loader, called the "bootstrap class loader", does not itself have a parent but may serve as the parent of a ClassLoader instance.

Normally, the Java virtual machine loads classes from the local file system in a platform-dependent manner. For example, on UNIX systems, the virtual machine loads classes from the directory defined by the CLASSPATH environment variable.

However, some classes may not originate from a file; they may originate from other sources, such as the network, or they could be constructed by an application. The method defineClass converts an array of bytes into an instance of class Class. Instances of this newly defined class can be created using Class.newInstance.

The methods and constructors of objects created by a class loader may reference other classes. To determine the class(es) referred to, the Java virtual machine invokes the loadClass method of the class loader that originally created the class.

For example, an application could create a network class loader to download class files from a server. Sample code might look like:

ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();
. . .
The network class loader subclass must define the methods findClass and loadClassData to load a class from the network. Once it has downloaded the bytes that make up the class, it should use the method defineClass to create a class instance. A sample implementation is:

class NetworkClassLoader extends ClassLoader {
String host;
int port;

public Class findClass(String name) {
byte[] b = loadClassData(name);
return defineClass(name, b, 0, b.length);
}

private byte[] loadClassData(String name) {
// load the class data from the connection
. . .
}
}

kapok

常用鏈接

留言簿(28)

隨筆分類

隨筆檔案

Corba

EAI

Online Document

Open Source

Portal

RSS Links

Weblogic

不錯的鏈接

工具集合

數據倉庫相關

搜索

最新評論

閱讀排行榜

評論排行榜


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 簡化JavaMail：小巧 Jakarta Commons-Email 簡單教程讀"Under the Hood of J2EE Clustering" J2EE集群 Phase x509數字證書介紹 SSL※ X509 了解安全性斷言標記語言架構藍圖--軟件架構 "4+1" 視圖模型主動對象 Profile,Stereotype,TaggedValue與OCL漫談 Drools 為你的業務邏輯提供框架（翻譯）