chenweicai

　　答：規(guī)范內(nèi)容包括Bean提供者，應(yīng)用程序裝配者，EJB容器，EJB配置工具，EJB服務(wù)提供者，系統(tǒng)管理員。這里面，EJB容器是EJB之所以能夠運(yùn)行的核心。EJB容器管理著EJB的創(chuàng)建，撤消，激活，去活，與數(shù)據(jù)庫(kù)的連接等等重要的核心工作。JSP,Servlet,EJB,JNDI,JDBC,JMS.....

　　2、EJB與JAVA BEAN的區(qū)別?

　　答：Java Bean 是可復(fù)用的組件，對(duì)Java Bean并沒(méi)有嚴(yán)格的規(guī)范，理論上講，任何一個(gè)Java類都可以是一個(gè)Bean。但通常情況下，由于Java Bean是被容器所創(chuàng)建(如Tomcat)的，所以Java Bean應(yīng)具有一個(gè)無(wú)參的構(gòu)造器，另外，通常Java Bean還要實(shí)現(xiàn)Serializable接口用于實(shí)現(xiàn)Bean的持久性。Java Bean實(shí)際上相當(dāng)于微軟COM模型中的本地進(jìn)程內(nèi)COM組件，它是不能被跨進(jìn)程訪問(wèn)的。Enterprise Java Bean 相當(dāng)于DCOM，即分布式組件。它是基于Java的遠(yuǎn)程方法調(diào)用(RMI)技術(shù)的，所以EJB可以被遠(yuǎn)程訪問(wèn)(跨進(jìn)程、跨計(jì)算機(jī))。但EJB必須被布署在諸如Webspere、WebLogic這樣的容器中，EJB客戶從不直接訪問(wèn)真正的EJB組件，而是通過(guò)其容器訪問(wèn)。EJB容器是EJB組件的代理，EJB組件由容器所創(chuàng)建和管理。客戶通過(guò)容器來(lái)訪問(wèn)真正的EJB組件。

　　2、EJB是基于哪些技術(shù)實(shí)現(xiàn)的?并說(shuō)出SessionBean和EntityBean的區(qū)別，StatefulBean和StatelessBean的區(qū)別。

　　答：EJB包括Session Bean、Entity Bean、Message Driven Bean，基于JNDI、RMI、JAT等技術(shù)實(shí)現(xiàn)。

　　SessionBean在J2EE應(yīng)用程序中被用來(lái)完成一些服務(wù)器端的業(yè)務(wù)操作，例如訪問(wèn)數(shù)據(jù)庫(kù)、調(diào)用其他EJB組件。EntityBean被用來(lái)代表應(yīng)用系統(tǒng)中用到的數(shù)據(jù)。

　　對(duì)于客戶機(jī)，SessionBean是一種非持久性對(duì)象，它實(shí)現(xiàn)某些在服務(wù)器上運(yùn)行的業(yè)務(wù)邏輯。

　　對(duì)于客戶機(jī)，EntityBean是一種持久性對(duì)象，它代表一個(gè)存儲(chǔ)在持久性存儲(chǔ)器中的實(shí)體的對(duì)象視圖，或是一個(gè)由現(xiàn)有企業(yè)應(yīng)用程序?qū)崿F(xiàn)的實(shí)體。

　　Session Bean 還可以再細(xì)分為 Stateful Session Bean 與 Stateless Session Bean ，這兩種的 Session Bean都可以將系統(tǒng)邏輯放在 method之中執(zhí)行，不同的是 Stateful Session Bean 可以記錄呼叫者的狀態(tài)，因此通常來(lái)說(shuō)，一個(gè)使用者會(huì)有一個(gè)相對(duì)應(yīng)的 Stateful Session Bean 的實(shí)體。Stateless Session Bean 雖然也是邏輯組件，但是他卻不負(fù)責(zé)記錄使用者狀態(tài)，也就是說(shuō)當(dāng)使用者呼叫 Stateless Session Bean 的時(shí)候，EJB Container 并不會(huì)找尋特定的 Stateless Session Bean 的實(shí)體來(lái)執(zhí)行這個(gè) method。換言之，很可能數(shù)個(gè)使用者在執(zhí)行某個(gè) Stateless Session Bean 的 methods 時(shí)，會(huì)是同一個(gè) Bean 的 Instance 在執(zhí)行。從內(nèi)存方面來(lái)看， Stateful Session Bean 與 Stateless Session Bean 比較， Stateful Session Bean 會(huì)消耗 J2EE Server 較多的內(nèi)存，然而 Stateful Session Bean 的優(yōu)勢(shì)卻在于他可以維持使用者的狀態(tài)。

　　3、EJB與JAVA BEAN的區(qū)別?

　　答：Java Bean 是可復(fù)用的組件，對(duì)Java Bean并沒(méi)有嚴(yán)格的規(guī)范，理論上講，任何一個(gè)Java類都可以是一個(gè)Bean。但通常情況下，由于Java Bean是被容器所創(chuàng)建(如Tomcat)的，所以Java Bean應(yīng)具有一個(gè)無(wú)參的構(gòu)造器，另外，通常Java Bean還要實(shí)現(xiàn)Serializable接口用于實(shí)現(xiàn)Bean的持久性。Java Bean實(shí)際上相當(dāng)于微軟COM模型中的本地進(jìn)程內(nèi)COM組件，它是不能被跨進(jìn)程訪問(wèn)的。Enterprise Java Bean 相當(dāng)于DCOM，即分布式組件。它是基于Java的遠(yuǎn)程方法調(diào)用(RMI)技術(shù)的，所以EJB可以被遠(yuǎn)程訪問(wèn)(跨進(jìn)程、跨計(jì)算機(jī))。但EJB必須被布署在諸如Webspere、WebLogic這樣的容器中，EJB客戶從不直接訪問(wèn)真正的EJB組件，而是通過(guò)其容器訪問(wèn)。EJB容器是EJB組件的代理，EJB組件由容器所創(chuàng)建和管理。客戶通過(guò)容器來(lái)訪問(wèn)真正的EJB組件。

　　EJB包括(SessionBean,EntityBean)說(shuō)出他們的生命周期，及如何管理事務(wù)的?

　　SessionBean：Stateless Session Bean 的生命周期是由容器決定的，當(dāng)客戶機(jī)發(fā)出請(qǐng)求要建立一個(gè)Bean的實(shí)例時(shí)，EJB容器不一定要?jiǎng)?chuàng)建一個(gè)新的Bean的實(shí)例供客戶機(jī)調(diào)用，而是隨便找一個(gè)現(xiàn)有的實(shí)例提供給客戶機(jī)。當(dāng)客戶機(jī)第一次調(diào)用一個(gè)Stateful Session Bean 時(shí)，容器必須立即在服務(wù)器中創(chuàng)建一個(gè)新的Bean實(shí)例，并關(guān)聯(lián)到客戶機(jī)上，以后此客戶機(jī)調(diào)用Stateful Session Bean 的方法時(shí)容器會(huì)把調(diào)用分派到與此客戶機(jī)相關(guān)聯(lián)的Bean實(shí)例。

　　EntityBean：Entity Beans能存活相對(duì)較長(zhǎng)的時(shí)間，并且狀態(tài)是持續(xù)的。只要數(shù)據(jù)庫(kù)中的數(shù)據(jù)存在，Entity beans就一直存活。而不是按照應(yīng)用程序或者服務(wù)進(jìn)程來(lái)說(shuō)的。即使EJB容器崩潰了，Entity beans也是存活的。Entity Beans生命周期能夠被容器或者 Beans自己管理。

　　EJB通過(guò)以下技術(shù)管理實(shí)務(wù)：對(duì)象管理組織(OMG)的對(duì)象實(shí)務(wù)服務(wù)(OTS)，Sun Microsystems的Transaction Service(JTS)、Java Transaction API(JTA)，開(kāi)發(fā)組(X/Open)的XA接口。

　　4、EJB的角色和三個(gè)對(duì)象

　　答：一個(gè)完整的基于EJB的分布式計(jì)算結(jié)構(gòu)由六個(gè)角色組成，這六個(gè)角色可以由不同的開(kāi)發(fā)商提供，每個(gè)角色所作的工作必須遵循Sun公司提供的EJB規(guī)范，以保證彼此之間的兼容性。這六個(gè)角色分別是EJB組件開(kāi)發(fā)者(Enterprise Bean Provider) 、應(yīng)用組合者(Application Assembler)、部署者(Deployer)、EJB 服務(wù)器提供者(EJB Server Provider)、EJB 容器提供者(EJB Container Provider)、系統(tǒng)管理員(System Administrator)

　　三個(gè)對(duì)象是Remote(Local)接口、Home(LocalHome)接口，Bean類
5、EJB容器提供的服務(wù)

　　答：主要提供聲明周期管理、代碼產(chǎn)生、持續(xù)性管理、安全、事務(wù)管理、鎖和并發(fā)行管理等服務(wù)。

　　6、EJB規(guī)范規(guī)定EJB中禁止的操作有哪些?

　　答：1.不能操作線程和線程API(線程API指非線程對(duì)象的方法如notify,wait等)，2.不能操作awt，3.不能實(shí)現(xiàn)服務(wù)器功能，4.不能對(duì)靜態(tài)屬生存取，5.不能使用IO操作直接存取文件系統(tǒng)，6.不能加載本地庫(kù).，7.不能將this作為變量和返回，8.不能循環(huán)調(diào)用。

　　7、remote接口和home接口主要作用

　　答：remote接口定義了業(yè)務(wù)方法，用于EJB客戶端調(diào)用業(yè)務(wù)方法。

　　home接口是EJB工廠用于創(chuàng)建和移除查找EJB實(shí)例

　　8、bean 實(shí)例的生命周期

　　答：對(duì)于Stateless Session Bean、Entity Bean、Message Driven Bean一般存在緩沖池管理，而對(duì)于Entity Bean和Statefull Session Bean存在Cache管理，通常包含創(chuàng)建實(shí)例，設(shè)置上下文、創(chuàng)建EJB Object(create)、業(yè)務(wù)方法調(diào)用、remove等過(guò)程，對(duì)于存在緩沖池管理的Bean，在create之后實(shí)例并不從內(nèi)存清除，而是采用緩沖池調(diào)度機(jī)制不斷重用實(shí)例，而對(duì)于存在Cache管理的Bean則通過(guò)激活和去激活機(jī)制保持Bean的狀態(tài)并限制內(nèi)存中實(shí)例數(shù)量。

　　9、EJB的激活機(jī)制

　　答：以Stateful Session Bean 為例：其Cache大小決定了內(nèi)存中可以同時(shí)存在的Bean實(shí)例的數(shù)量，根據(jù)MRU或NRU算法，實(shí)例在激活和去激活狀態(tài)之間遷移，激活機(jī)制是當(dāng)客戶端調(diào)用某個(gè)EJB實(shí)例業(yè)務(wù)方法時(shí)，如果對(duì)應(yīng)EJB Object發(fā)現(xiàn)自己沒(méi)有綁定對(duì)應(yīng)的Bean實(shí)例則從其去激活Bean存儲(chǔ)中(通過(guò)序列化機(jī)制存儲(chǔ)實(shí)例)回復(fù)(激活)此實(shí)例。狀態(tài)變遷前會(huì)調(diào)用對(duì)應(yīng)的ejbActive和ejbPassivate方法。

　　10、EJB的幾種類型

　　答：會(huì)話(Session)Bean ，實(shí)體(Entity)Bean 消息驅(qū)動(dòng)的(Message Driven)Bean

　　會(huì)話Bean又可分為有狀態(tài)(Stateful)和無(wú)狀態(tài)(Stateless)兩種

　　實(shí)體Bean可分為Bean管理的持續(xù)性(BMP)和容器管理的持續(xù)性(CMP)兩種

　　11、客服端調(diào)用EJB對(duì)象的幾個(gè)基本步驟

　　答：設(shè)置JNDI服務(wù)工廠以及JNDI服務(wù)地址系統(tǒng)屬性，查找Home接口，從Home接口調(diào)用Create方法創(chuàng)建Remote接口，通過(guò)Remote接口調(diào)用其業(yè)務(wù)方法

? bin???????????????????啟動(dòng)和關(guān)閉JBoss的腳本
??client????????????????客戶端與JBoss通信所需的的Java庫(kù)（JARs）
??docs??????????????????配置的樣本文件（數(shù)據(jù)庫(kù)配置等）
??doc/dtd???????????????在JBoss中使用的各種XML文件的DTD。
??lib???????????????????一些JAR，JBoss啟動(dòng)時(shí)加載，且被所有JBoss配置共享。（不要把你的庫(kù)放在這里）
??server????????????????各種JBoss配置。每個(gè)配置必須放在不同的子目錄。子目錄的名字表示配置的名字。JBoss包含3個(gè)默認(rèn)的配置：minimial，default和all。
??server/all????????????JBoss的完全配置，啟動(dòng)所有服務(wù)，包括集群和IIOP。
??server/default????????JBoss的默認(rèn)配置。在沒(méi)有在JBoss命令航中指定配置名稱時(shí)使用。
??server/default/conf???JBoss的配置文件。
??server/default/data???JBoss的數(shù)據(jù)庫(kù)文件。比如，嵌入的數(shù)據(jù)庫(kù)，或者JBossMQ。
??server/default/deploy?JBoss的熱部署目錄。放到這里的任何文件或目錄會(huì)被JBoss自動(dòng)部署EJB、WAR、EAR，甚至服務(wù)。
??server/default/lib????一些JAR，JBoss在啟動(dòng)特定配置時(shí)加載他們。?(all和minimial配置也包含這個(gè)和下面兩個(gè)目錄。）
??server/default/log????JBoss的日志文件。
??server/default/tmp????JBoss的臨時(shí)文件。

啟動(dòng)時(shí)可用-c參數(shù)指定要啟動(dòng)的配置：run.bat?-c?config-name

三個(gè)基本class
EJB最少也需要三個(gè)class, remote interface, home interface, and bean implementation(bean行為).

1. remote interface 用來(lái)揭示EJB對(duì)外的一些方法.在這個(gè)例子中,the remote interface 就是org.jboss.docs.interest.Interest.

?

2.home interface 是用來(lái)規(guī)定怎樣創(chuàng)建一個(gè)實(shí)現(xiàn)remote interface的bean. 在本例中home interface 是 org.jboss.docs.InterestHome.

3.bean implementation 是提供方法的實(shí)現(xiàn),這些方法在上述兩種interface中都有規(guī)定了,在本例中是兩個(gè)方法: calculateCompoundInterest和create().

這個(gè)bean implementation 是 org.jboss.docs.interest.InterestBean.

?

這些classes必須打包進(jìn)一個(gè)JAR文件中,JAR文件中包含了目錄結(jié)構(gòu)和包的層次.在本例中,這些classes是在包org.jboss.docs.interest, 這樣他們需要在目錄org/jboss/docs/interest/ 下.

部署發(fā)布描述器ejb-jar.xml和jboss.xml
在JAR文檔創(chuàng)建之前,還需要一個(gè)叫META-INF的目錄,這是存放部署發(fā)布描述器的(一般叫ejb-jar.xml).大部分商用EJB Server提供圖形化工具來(lái)編輯這個(gè) 描述器.在JBoss中需要手工:

在本例中,一個(gè)包中只有一個(gè)EJB 這樣就不用描述多個(gè)EJB之間是怎樣交互的.

盡管對(duì)于所有的EJB服務(wù)器,ejb-jar.xml部署描述器的格式是一樣的(更多精確的定義可以從sun得到DTD).它并沒(méi)有規(guī)定所有的必須的信息,比如如何將EJB-NAME和JNDI naming service聯(lián)系起來(lái).

缺省情況下,JNDI name將使用在ejb-jar.xml中<ejb-name>XXX</ejb-name>中的XXX來(lái)使用EJB的home interface.

但是如果有多個(gè)EJB,在ejb-jar.xml中,在<ejb-name>XXX</ejb-name>中XXX就不能用同一個(gè)名字了,一般格式是"[application name]/[bean name]".

那么如果再按照缺省情況,JNDI name就可能找不到你的應(yīng)用程序的入口了,因此我們要特別規(guī)定一下.這就需要在jboss.xml中規(guī)定:

這樣,你所有叫Interest文件都被梆定到JNDI name:interest/Interest下面

jndi.properties
雖然有了上面你的應(yīng)用程序和JNDI name的梆定,但是一旦部署發(fā)布到JBoss服務(wù)器上,你還需要一個(gè)jndi.properties文件,以告訴調(diào)用你程序的客戶端請(qǐng)求到哪里去初始化JNDI naming service.

在本例中,客戶端請(qǐng)求將尋找Interest 這個(gè)bean, 然后得到這個(gè)bean的home interface. home interface是用來(lái)得到這個(gè)bean的remote interface.最后,客戶端請(qǐng)求將通過(guò)remote interface來(lái)使用由EJB提供的功能.

greet
  +-- Greet.java
  +-- GreetHome.java
  +-- GreetBean.java
META-INF
  +-- ejb-jar.xml
  +-- jboss.xml

package greet;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
/**
 * 這個(gè)接口為‘Greet’定義了遠(yuǎn)程接口
public interface Greet extends EJBObject 
{
    public double calculateMagic(double seed) throws RemoteException;
}

package greet;
import java.io.Serializable;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface GreetHome extends EJBHome 
{
 Greet create() throws RemoteException, CreateException;
}

package greet;
import java.rmi.RemoteException; 
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
public class GreetBean implements SessionBean 
{
 public double calculateMagic(double seed) {
  System.out.println ("Someone called `calculateMagic!'");
return seed * Math.random();
 }
 public GreetBean() {}
public void ejbCreate() {
 System.out.println("Create Greet EJB.");
}
public void ejbRemove() {
 System.out.println("Remove Greet EJB.");
}
public void ejbActivate() {
 System.out.println("Activate Greet EJB");
}
 public void ejbPassivate() {
  System.out.println("Passivate Greet EJB");
 }
/**
* Set context for `Greet' EJB
*/
 public void setSessionContext(SessionContext sc) {
  System.out.println("Set context for Greet EJB");
 }
}

javac *.java -classpath \
/usr/jb_tom/jboss/lib/ext/jboss-j2ee.jar:.

?

根據(jù)EJB規(guī)范，要想將EJB成功地部署到EJB服務(wù)器上，必須為EJB服務(wù)器提供相應(yīng)的部署描述符。部署描述符對(duì)所要部署的EJB進(jìn)行了說(shuō)明，包括該EJB的遠(yuǎn)程描述符、本地描述符和Bean類等信息。由于EJB服務(wù)器只有在獲得這些基本信息后才能正確完成EJB的部署，因此編寫(xiě)EJB描述符是開(kāi)發(fā)EJB時(shí)必不可少的一個(gè)環(huán)節(jié)。

對(duì)于不同的EJB服務(wù)器來(lái)說(shuō)，部署同一EJB時(shí)所需的部署描述符可能并不相同。在JBoss平臺(tái)上，任何將要被部署的EJB都必須提供ejb-jar.xml和jboss.xml兩個(gè)文件，這兩個(gè)文件均位于JAR包中的META-INF目錄下，用于對(duì)將要部署的EJB進(jìn)行簡(jiǎn)要的說(shuō)明。

ejb-jar.xml

ejb-jar.xml是EJB規(guī)范定義的標(biāo)準(zhǔn)部署描述符，在任何EJB服務(wù)器上部署EJB時(shí)都需要用到該部署描述符。本例中用到的ejb-jar.xml代碼如下所示：

<?xml version="1.0" encoding="Cp1252"?> <ejb-jar> <description>jBoss test application </description> <display-name>Test</display-name> <enterprise-beans> <session> <ejb-name>GreetEJB</ejb-name> <home>greet.GreetHome</home> <remote>greet.Greet</remote> <ejb-class>greet.GreetBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean</transaction-type> </session> </enterprise-beans> </ejb-jar>

jboss.xml

雖然ejb-jar.xml對(duì)所有的EJB服務(wù)器都是通用的，但它并沒(méi)有為EJB服務(wù)器提供將要被部署的EJB的全部信息。為了能夠?qū)JB的部署進(jìn)行更靈活的控制，大部分EJB服務(wù)器都要求EJB開(kāi)發(fā)者同時(shí)提供另外一個(gè)文件來(lái)對(duì)將要部署的EJB進(jìn)行描述，在JBoss中該文件為jboss.xml，它也位于JAR包中的META-INF目錄中。jboss.xml中可以對(duì)EJB對(duì)應(yīng)的JNDI名字以及相應(yīng)的持久性進(jìn)行說(shuō)明，在本例中用到的jboss.xml如下所示：

<?xml version="1.0" encoding="ISO-8859-1"?> <jboss> <enterprise-beans> <session> <ejb-name>GreetEJB</ejb-name> <jndi-name>GreetingEJB</jndi-name> </session> <secure>false</secure> </enterprise-beans> <resource-managers/> </jboss>

開(kāi)發(fā)EJB的最后一步是將其中所有的類文件和相應(yīng)的部署描述符壓縮成JAR包，然后部署到EJB服務(wù)器上。在本例中，JAR包的生成可以通過(guò)下面這條命令來(lái)實(shí)現(xiàn)：

jar cf greetejb.jar greet/*.class META-INF/*.xml

該命令將greet目錄下的.class文件和META-INF目錄下的.xml文件壓縮成greetejb.jar文件。如果想知道生成的JAR包是否正確地包含了所有的文件，可以用命令：

jar cvf greetejb.jar

0 Sun May 24 15:32:10 CST 2002 META-INF/
68 Sun May 24 15:32:10 CST 2002 META-INF/MANIFEST.MF
1007 Sun May 24 14:35:46 CST 2002 greet/GreetBean.class
209 Sun May 24 14:35:46 CST 2002 greet/Greet.class
251 Sun May 24 14:35:46 CST 2002 greet/GreetHome.class
493 Sun May 24 08:40:00 CST 2002 META-INF/ejb-jar.xml
303 Sun May 24 08:43:22 CST 2002 META-INF/jboss.xml

cp greetejb.jar /usr/jb_tom/jboss/deploy/

[INFO,ContainerFactory] Deploying GreetEJB
[INFO,GreetEJB] Initializing
[INFO,GreetEJB] Initialized
[INFO,GreetEJB] Starting
[INFO,GreetEJB] Started

EJB存在的價(jià)值在于為其客戶提供相應(yīng)的服務(wù)，EJB客戶包含的范圍相當(dāng)廣泛，可以是另外的EJB、普通的JavaBean、JSP頁(yè)面、Applet或者標(biāo)準(zhǔn)的Java應(yīng)用程序。GreetClient.java是已經(jīng)部署好的EJB的客戶程序，其完整的源碼如下所示：

import javax.naming.*; import java.util.Hashtable; import javax.rmi.PortableRemoteObject; import greet.*; class GreetClient { public static void main(String[] args) { System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.Naming ContextFactory"); System.setProperty("java.naming.provider.url", "localhost:1099"); try { // Get a naming context InitialContext jndiContext = new InitialContext(); System.out.println（"Got context"）; Object ref = jndiContext.lookup("GreetingEJB"); System.out.println("Got reference"); GreetHome home = (GreetHome) PortableRemoteObject.narrow (ref, GreetHome.class); Greet greet = home.create(); System.out.print("The magic number from server is "); System.out.println(greet.calculateMagic(123.456)); } catch(Exception e) { System.out.println(e.toString()); } } }

用下面的命令對(duì)EJB客戶端程序進(jìn)行編譯：

javac GreetClient.java \ -classpath /usr/jb_tom/jboss/lib/ext/jboss-j2ee.jar:.

如果一切正常，就可以運(yùn)行客戶端程序來(lái)對(duì)EJB進(jìn)行測(cè)試了，命令如下：

java -cp \ $CLASSPATH:/usr/jb_tom/jboss/client/jboss-client.jar:. \ GreetClient

小結(jié)

本文以一個(gè)無(wú)狀態(tài)的會(huì)話Bean為例，講述了在JBoss平臺(tái)上開(kāi)發(fā)和部署EJB的全過(guò)程，對(duì)JBoss的安裝、EJB的創(chuàng)建、EJB的部署及EJB的測(cè)試做了簡(jiǎn)要介紹。作為一個(gè)開(kāi)放源碼的EJB服務(wù)器，JBoss已經(jīng)開(kāi)始被越來(lái)越多的企業(yè)所接受，基于JBoss的成功案例屢見(jiàn)不鮮。有關(guān)JBoss的更多信息，請(qǐng)?jiān)L問(wèn)JBoss的網(wǎng)站http://www.jboss.org。

Java

Description

Executes a Java class within the running (Ant) VM or forks another VM if specified.

If odd things go wrong when you run this task, set fork="true" to use a new JVM.

As of Ant 1.6.3, you can interact with a forked VM, as well as sending input to it via the input and inputstring attributes.

Parameters

Parameters specified as nested elements

arg and jvmarg

Use nested <arg> and <jvmarg> elements to specify arguments for the Java class and the forked VM respectively. See Command line arguments.

sysproperty

Use nested <sysproperty> elements to specify system properties required by the class. These properties will be made available to the VM during the execution of the class (either ANT's VM or the forked VM). The attributes for this element are the same as for environment variables.

syspropertyset

You can specify a set of properties to be used as system properties with syspropertysets.

since Ant 1.6.

classpath

Java's classpath attribute is a PATH like structureand can also be set via a nested classpath element.

bootclasspath

The location of bootstrap class files can be specified using this PATH like structure- will be ignored if fork is not true or the target VM doesn't support it (i.e. Java 1.1).

since Ant 1.6.

env

It is possible to specify environment variables to pass to the forked VM via nested env elements. See the description in the section about exec

Settings will be ignored if fork is disabled.

permissions

Security permissions can be revoked and granted during the execution of the class via a nested permissions element. For more information please see permissions

When the permission RuntimePermission exitVM has not been granted (or has been revoked) the System.exit() call will be intercepted and treated like indicated in failonerror.

Note:
If you do not specify permissions, a set of default permissions will be added to your Java invocation to make sure that the ant run will continue or terminated as indicated by failonerror. All permissions not granted per default will be checked by whatever security manager was already in place. exitVM will be disallowed.

Settings will be ignored if fork is enabled.

since Ant 1.6.

assertions

You can control enablement of Java 1.4 assertions with an <assertions>subelement.

Assertion statements are currently ignored in non-forked mode.

since Ant 1.6.

A nested I/O Redirectorcan be specified. In general, the attributes of the redirector behave as the corresponding attributes available at the task level. The most notable peculiarity stems from the retention of the <java> attributes for backwards compatibility. Any file mapping is done using a null sourcefile; therefore not all Mappertypes will return results. When no results are returned, redirection specifications will fall back to the task level attributes. In practice this means that defaults can be specified for input, output, and error output files.

Errors and return codes

Similarly, if failonerror="false" and fork="false" , then <java>must return 0 otherwise the build will exit, as the class was run by the build JVM.

JAR file execution

The parameter of the jar attribute is of type File; that is, the parameter is resolved to an absolute file relative to the base directory of the project, not the directory in which the Java task is run. If you need to locate a JAR file relative to the directory the task will be run in, you need to explicitly create the full path to the JAR file.

When using the jar attribute, all classpath settings are ignored according to Sun's specification.

Examples

				       <java classname="test.Main">
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				       <java jar="dist/test.jar"
           fork="true"
           failonerror="true"
           maxmemory="128m"
           >
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				       <java
           dir="${exec.dir}"
           jar="${exec.dir}/dist/test.jar"
           fork="true"
           failonerror="true"
           maxmemory="128m"
           >
         <arg value="-h"/>
         <classpath>
           <pathelement location="dist/test.jar"/>
           <pathelement path="${java.class.path}"/>
         </classpath>
       </java>

		

				  <java classname="test.Main"/>
		

				  <java classname="test.Main"
        fork="yes" >
    <sysproperty key="DEBUG" value="true"/>
    <arg value="-h"/>
    <jvmarg value="-Xrunhprof:cpu=samples,file=log.txt,depth=3"/>
  </java>

		

				  <java classname="ShowJavaVersion" classpath="."
        jvm="path-to-java14-home/bin/java" fork="true"
        taskname="java1.4" >

		

Note: you can not specify the (highly deprecated) MSJVM, "jview.exe" as the JVM, as it takes different parameters for other JVMs, That JVM can be started from <exec> if required.

package proxy;
/**
?*
?* @author chen
?*
?*/
public interface Subject {
?abstract public void request();
?abstract public void request2();
}


package proxy;

/**
?*
?* @author chen
?*
?*/
public class RealSubject implements Subject {
?
?public RealSubject(){
?}

?public void request() {
??// TODO Auto-generated method stub
??System.out.println("From real subject.request().");
?}
?
?public void request2() {
??// TODO Auto-generated method stub
??System.out.println("From real subject.request2()");
?}
}

package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

/**
?*
?* @author chenweicai
?*
?*/
public class DynamicSubject implements InvocationHandler {
?
?private Object sub;
?
?public DynamicSubject(){
?}
?
?public DynamicSubject(Object obj){
??this.sub = obj;
?}

?public Object invoke(Object proxy, Method method, Object[] args)
???throws Throwable {
??// TODO Auto-generated method stub
???? System.out.println("before calling " + method);
???? method.invoke(sub,args);
???? System.out.println("after calling " + method);
??return null;
?}

}


package proxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Constructor;
import java.lang.reflect.Proxy;

/**
?*
?* @author chen
?*
?*/
public class Client {
?static public void main(String[] args)
??????? throws Throwable{
??? RealSubject rs = new RealSubject();? //在這里指定被代理類
??? InvocationHandler ds = new DynamicSubject(rs);? //初始化代理類
??? Class cls = rs.getClass();
??
??? //以下是分解步驟
??? /*Class c = Proxy.getProxyClass(cls.getClassLoader(),cls.getInterfaces()) ;
??? Constructor ct=c.getConstructor(new Class[]{InvocationHandler.class});
??? Subject subject =(Subject) ct.newInstance(new Object[]{ds});*/
??
??? //以下是一次性生成
??? Subject subject = (Subject) Proxy.newProxyInstance(cls.getClassLoader(),
??? cls.getInterfaces(),ds );

??? subject.request2();
?? }
}