- 浏览: 231664 次
- 性别:
- 来自: 河南
最新评论
-
wbbcz4426493:
文章写的不错。继续加油。
对IBatis分页的改进,使ibatis支持hibernate式的物理分页 -
robertzsl:
已经没用了,不过总结的还不错。
JS实现Html File控件赋值 -
liujunhao225:
感谢楼主,我遇到了同样的问题。相信看了你的文章一定可以解决。
dom4j解析xml-取消doctype中DTD验证设置 -
zyguo1006:
写的很好,例子很生动.
JavaScript之call()和apply() -
yyfmp3:
<beans xmlns="http://ww ...
对IBatis分页的改进,使ibatis支持hibernate式的物理分页
项目中一直都在使用EJB(无状态SessionBean),但由于EJB在项目中主要起到分布式作用,因此,都是非常简单的应用,对EJB的环境配置、事务等功能都未曾细研,在此转自http://infocenter.apusic.com/help/index.jsp?topic=/aas/v6/ejb_env.html 上的文章,以备查阅!
摘要
本节提供对Apusic应用服务器中的EJB环境的介绍,包括作为EJB环境的JNDI命名上下文(Context)的介绍、如何使用EJB的环境项(environment entry)、如何在EJB环境中设置对资源连接创建器的引用、如何在EJB环境中设置对应用服务器中被管理对象的引用,最后是存在于应用服务器命名环境中、可访问的javax.transaction.UserTransaction接口的介绍。
EJB组件编程模型提供了一个将企业应用业务逻辑的开发和部署分开的灵活模型。通常在企业应用开发、部署和运行过程中,随着业务需求的不断变化,应用的业务逻辑也在随之发生变化,另外,为提高EJB的可重用特性,需要一种标准的方式,将组件逻辑与实际生产环境中需要访问的其他资源的具体信息分离,因此,EJB编程模型中,引入了EJB环境。
EJB环境实际上是伴随EJB的一个运行时由容器负责管理的JNDI命名上下文,其内容来自于开发者在部署描述中设置和声明的信息。通常,对于业务逻辑中易发生变化的内容,以及组件中需要访问的实际生产环境中的资源(如数据库、邮件服务等)信息,开发者可以将其从组件代码中分离出来,放置到EJB环境有关的部署描述中,这样,在运行时,可只以通过修改部署描述来修改应用的业务逻辑并使组件适应新的部署环境。
EJB环境中提供对如下内容的设置和定制:
-
使用环境项(environment entry)进行一般的业务逻辑定制 ;
-
定制对其它EJB组件的引用;
-
通过资源管理器的连接创建器引用(resouce manager connection factory reference)指定资源管理器的连接创建器;
-
使用资源环境引用定义伴随某资源的被管理对象接口;
当组件被部署到应用服务器,容器将对部署描述中有关EJB环境设置的内容进行管理,并将其绑定到一个容器管理的命名上下文(naming context)上,组件代码中通过JNDI API访问EJB环境中定义的内容。
需要注意的是,对于不同的EJB组件,其部署描述中定义的环境项(environment entry)集合是不能共享的;只有同一个EJB组件的所有实例,才能共享相同的环境项集合。另外,在EJB规范中规定,在运行时,实例只能对环境项的进行只读操作,不能试图修改环境项。
如果同一个EJB组件被多次部署到容器中,则每一次部署都会被视为不同的组件而生成不同的Home实例,并对不同的Home实例伴随不同的环境项集合,只有属于同一个Home实例的EJB实例,才共享相同的环境项集合。
EJB组件模型中的环境项,提供了在装配和部署时,通过修改部署描述,改变组件业务逻辑的方法。
当组件被部署到应用服务器时,容器将把组件部署描述中设置和声明的环境项保存到EJB环境中的一个名为“java:comp/env的”JNDI命名上下文中,包括此命名上下文直接或非直接的子上下文。在运行时组件可通过JNDI API对这些环境项进行访问。环境项的类型则由开发者在部署描述中声明。下面是在EJB组件业务方法中访问环境项的范例:
public class EmployeeServiceEJB implements SessionBean { ... public void setTaxInfo(int numberOfExemptions, ...) throws InvalidNumberOfExemptionsException { ... // Obtain the enterprise bean’s environment naming context. Context initCtx = new InitialContext(); Context myEnv = (Context)initCtx.lookup("java:comp/env"); // Obtain the maximum number of tax exemptions // configured by the Deployer. Integer max = (Integer)myEnv.lookup(“maxExemptions”); // Obtain the minimum number of tax exemptions // configured by the Deployer. Integer min = (Integer)myEnv.lookup(“minExemptions”); // Use the environment entries to customize business logic. if (numberOfExeptions > Integer.intValue(max) || numberOfExemptions < Integer.intValue(min)) throw new InvalidNumberOfExemptionsException(); // Get some more environment entries. These environment // entries are stored in subcontexts. String val1 = (String)myEnv.lookup(“foo/name1”); Boolean val2 = (Boolean)myEnv.lookup(“foo/bar/name2”); // The enterprise bean can also lookup using full pathnames. Integer val3 = (Integer) initCtx.lookup("java:comp/env/name3"); Integer val4 = (Integer) initCtx.lookup("java:comp/env/foo/name4"); ... } }
对EJB代码中访问的环境项,需要在部署描述文件中使用env-entry元素进行声明,每个env-entry元素代表EJB环境中的一个环境项。env-entry元素的结构如下图:
env-entry元素结构
一个env-entry元素中包含一个可选的描述环境项的子元素description;一个声明相对于java:comp/env命名上下文的环境项名字的元素env-entry-name;声明环境项值的Java类型(即通过JNDI的lookup方法返回的对象类型)的元素env-entry-type;一个表示环境项值的可选元素env-entry-value。
由于在运行时,每个EJB组件的环境项的作用域仅存在于本组件内部,因此,不同EJB组件是访问不到其它组件中定义的环境项的,因此不同的EJB组件采用相同的环境项名字,不会发生冲突。
环境项的值只能是以下几种类型:
-
java.lang.String;;
-
java.lang.Character;
-
java.lang.Integer;
-
java.lang.Boolean;
-
java.lang.Double;
-
java.lang.Byte;
-
java.lang.Short;
-
java.lang.Long;
-
java.lang.Float。
除了java.lang.Character类型的环境项值必须是一个字符之外,每一种类型的环境项值,必须符合对应的Java类型中定义的只接受一个字符串参数的构建器方法,所能接受的字符串参数的格式。
对应上一节中的例子,访问多个环境项的EmployeeServiceEJB,有如下的部署描述文件设置:
<enterprise-beans> <session> ... <ejb-name>EmployeeService</ejb-name> <ejb-class>EmployeeServiceEJB</ejb-class> ... <env-entry> <description> The maximum number of tax exemptions allowed to be set. </description> <env-entry-name>maxExemptions</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>15</env-entry-value> </env-entry> <env-entry> <description> The minimum number of tax exemptions allowed to be set. </description> <env-entry-name>minExemptions</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>1</env-entry-value> </env-entry> <env-entry> <env-entry-name>foo/name1</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>value1</env-entry-value> </env-entry> <env-entry> <env-entry-name>foo/bar/name2</env-entry-name> <env-entry-type>java.lang.Boolean</env-entry-type> <env-entry-value>true</env-entry-value> </env-entry> <env-entry> <description>Some description.</description> <env-entry-name>name3</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> </env-entry> <env-entry> <env-entry-name>foo/name4</env-entry-name> <env-entry-type>java.lang.Integer</env-entry-type> <env-entry-value>10</env-entry-value> </env-entry> ... </session> </enterprise-beans> ...
企业应用中,组件之间的相互引用可能会限制单个组件的可移植和可重用特性,在EJB组件的编程模型中,引入了EJB引用。即当某个EJB组件中需要访问应用中的其他EJB时,可以在部署描述中声明对其他EJB的引用,当应用被部署到服务器,由容器解析此引用,并将引用保存在EJB环境中,不需要在组件代码中包含特定的EJB的JNDI名称,这样,当组件被部署到不同的生产环境或被引用的组件发生变化,不需要修改组件代码即可改变EJB的引用目标。
在使用EJB引用时,开发者需要在部署描述中使用ejb-ref元素指定一个到其他EJB的引用项。此引用项包含在EJB环境中,并包含在java:comp/env命名上下文中,根据EJB规范,此引用的命名应在EJB环境中的ejb子上下文中,如:java:comp/env/ejb/RefName,组件代码中即可在EJB环境中使用JNDI的API查找被引用EJB的Home接口。
下面是访问EJB引用的代码范例:
public class EmployeeServiceEJB implements SessionBean { public void changePhoneNumber(...) { ... // Obtain the default initial JNDI context. Context initCtx = new InitialContext(); // Look up the home interface of the EmployeeRecord // enterprise bean in the environment. Object result = initCtx.lookup( "java:comp/env/ejb/EmplRecord"); // Convert the result to the proper type. EmployeeRecordHome emplRecordHome = (EmployeeRecordHome) javax.rmi.PortableRemoteObject.narrow(result, EmployeeRecordHome.class); ... } }
上面的例子中,在EmployeeServiceEJB的EJB环境中指定了一个名为ejb/EmplRecord的EJB引用,通过此引用可访问被引用的EJB的Home接口。
尽管EJB引用属于EJB环境中的一个项目,但不可在部署描述中使用env-entry元素对引用进行声明,必须使用ejb-ref或ejb-local-ref元素进行声明,每个ejb-ref或ejb-local-ref代表一个EJB引用。ejb-ref和ejb-local-ref元素的结构如下图:
ejb-ref和ejb-local-ref元素结构
ejb-ref和ejb-local-ref元素都描述了对其他EJB的引用,所不同的是,ejb-ref声明的是通过远程Home接口和使用远程接口访问被引用的EJB,而ejb-local-ref声明的是通过本地Home接口和使用本地接口访问被引用的EJB。
ejb-ref和ejb-local-ref都包含一个可选的description元素,用于对此引用提供描述信息;ejb-ref-name元素指定此EJB引用的引用名;ejb-ref-type用于指定引用的EJB组件的类型,可以是“Session”或“Entity”;home、local-home、remote和local元素分别用于指定被引用的EJB组件的远程Home接口、本地Home接口、远程接口和本地接口。
由于在运行时,每个EJB组件的EJB引用的作用域仅存在于本组件内部,因此,不同EJB组件是访问不到其它组件中定义的EJB引用的,因此不同的EJB组件采用相同的EJB引用名字,不会发生冲突。
下面是声明EJB引用的部署描述范例:
... <enterprise-beans> <session> ... <ejb-name>EmployeeService</ejb-name> <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class> ... <ejb-ref> <description> This is a reference to the entity bean that encapsulates access to employee records. </description> <ejb-ref-name>ejb/EmplRecord</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>EmployeeRecordHome</home> <remote>EmployeeRecord</remote> </ejb-ref> <ejb-ref> <ejb-ref-name>ejb/Payroll</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>PayrollHome</home> <remote>com.aardvark.payroll.Payroll</remote> </ejb-ref> <ejb-ref> <ejb-ref-name>ejb/PensionPlan</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>PensionPlanHome</home> <remote>PensionPlan</remote> </ejb-ref> ... </session> ... </enterprise-beans> ...
另外,开发者还需要在apusic-application.xml文件中,对应的EJB组件的设置中,使用ejb-ref或ejb-local-ref元素将引用名与被引用的EJB组件的JNDI名字进行映射。
apusic-application.xml中的ejb-ref和ejb-local-ref元素的结构如下图:
ejb-ref和ejb-local-ref元素结构
则上例中的EJB引用的配置在apusic-application中的配置如下:
<apusic-application> ... <module> ... <ejb> ... <session ejb-name="EmployeeService"> ... <ejb-ref> <ejb-ref-name>ejb/EmplRecord</ejb-ref-name> <jndi-name>ejb/EmplRecord</jndi-name> </ejb-ref> <ejb-ref> <ejb-ref-name>ejb/Payroll</ejb-ref-name> <jndi-name>ejb/Payroll</jndi-name> </ejb-ref> <ejb-ref> <ejb-ref-name>ejb/PensionPlan</ejb-ref-name> <jndi-name>ejb/PensionPlan</jndi-name> </ejb-ref> ... </session> ... </ejb> ... </module> ... </apusic-application>
开发者也可在ejb-jar部署描述中的ejb-ref或ejb-local-ref元素里使用可选的ejb-link元素来将ejb引用连接到具体的EJB组件。ejb-link元素的值必须是被引用的EJB组件的名字,即被引用的EJB组件的部署描述元素ejb-name的值。被引用的EJB组件可以是同一个应用中,与声明引用的EJB组件相同或不同的EJB模块中的EJB组件。
为了避免整个应用中在发生引用时所产生的EJB名称冲突,ejb-link元素的值必须遵循如下规则,即当被引用的EJB组件位于应用中的其他EJB模块,则在被引用的EJB组件的名字前必须加上被引用组件位于的EJB模块的模块路径,在被引用模块路径和被引用组件名之间使用“#”字符进行分隔。被引用模块路径是相对于当前的引用模块的路径。
如下例:
<enterprise-beans> <session> ... <ejb-name>EmployeeService</ejb-name> <ejb-class>com.wombat.empl.EmployeeServiceEJB</ejb-class> ... <ejb-ref> <ejb-ref-name>ejb/EmplRecord</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>com.wombat.empl.EmployeeRecordHome</home> <remote>com.wombat.empl.EmployeeRecord</remote> <ejb-link>EmployeeRecord</ejb-link> </ejb-ref> ... </session> ... <entity> <ejb-name>EmployeeRecord</ejb-name> <home>com.wombat.empl.EmployeeRecordHome</home> <remote>com.wombat.empl.EmployeeRecord</remote> ... </entity> ... </enterprise-beans> ...
下例是引用同一个应用中不同模块的EJB组件时,ejb-link的用法:
<entity> ... <ejb-name>OrderEJB</ejb-name> <ejb-class>com.wombat.orders.OrderEJB</ejb-class> ... <ejb-ref> <ejb-ref-name>ejb/Product</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>com.acme.orders.ProductHome</home> <remote>com.acme.orders.Product</remote> <ejb-link>../products/product.jar#ProductEJB</ejb-link> </ejb-ref> ... </entity>
注意 |
当在ejb-jar模块部署描述中的ejb-ref或ejb-local-ref元素里使用了ejb-link元素将EJB引用连接到了具体的EJB组件,则在apusic-application部署描述可以不使用ejb-ref或ejb-local-ref元素将引用名与被引用EJB组件的JNDI名进行映射。 |
Java EE平台中定义了三种可管理资源,JMS消息系统、可通过JDBC连接的数据库系统以及符合Java Connector Architecture规范的后端系统,应用可通过以上资源的连接创建器(Connection Factory)创建对以上资源的连接。应用服务器则对以上资源提供资源管理器,对应用中创建的资源连接进行管理,如对资源连接提供连接池、在事务中自动对连接进行征用(enlist)等。
Apusic应用服务器中提供对以上内容的实现,例如当应用通过javax.sql.DataSource接口从连接池中获取java.sql.Connection连接时,应用服务器中的资源管理器即对连接进行管理,不过,这些工作对于应用而言则是透明的,应用只根据接口提供的标准API对连接进行操作即可。
EJB组件中,不可避免将会使用某些资源,但是,实际生产环境中的资源情况是不同的,尤其是当EJB组件被装配到不同的生产环境的时候,因此,EJB组件模型在EJB环境中提供了资源管理器的连接创建器引用的机制,即应用中的代码通过资源连接创建器的逻辑名称,取得资源连接创建器对象,然后通过此对象创建与资源的连接。这样,当应用被部署到不同的生产环境,通过将逻辑名称映射到不同的资源,即可提高应用或组件的可重用特性,不用修改代码即可适应新的生产环境。
连接创建器的引用必须在EJB组件的部署描述中进行声明,引用是作为EJB环境中的一个特殊项而被声明的,根据EJB规范,推荐开发者所声明的引用位于不同的EJB环境中的子上下文(subcontext)中,如有关数据库连接的创建器引用名应位于java:comp/env/jdbc的子上下文中、有关JMS消息系统的连接创建器引用名应位于java:comp/env/jms的子上下文中、有关JavaMail的连接创建器引用名应位于java:comp/env/mail的子上下文中、有关URL连接创建器引用名应位于java:comp/env/url的子上下文中。
在部署描述中声明了连接创建器引用后,必须在部署描述中将引用映射到实际的资源,这个工作需要在apusic-application.xml中使用相应的部署描述元素将引用名与资源的JNDI名进行映射。
在完成了引用名与实际资源的映射后,组件在运行时即可通过JNDI的API对引用进行查找,然后通过连接创建器创建与特定资源的连接。
虽然连接创建器引用作为EJB环境的一部分,但是连接创建器的引用在ejb-jar中使用resource-ref元素声明每一个引用,而不是使用env-entry元素。
resource-ref元素的结构如下图:
resource-ref元素结构
EJB组件部署描述中的每个resource-ref元素声明一个连接创建器的引用,包含一个可选的用于对此引用提供文档信息的description元素;包含一个必需的声明引用名的res-ref-name元素、一个声明引用类型的res-ref元素、一个声明引用身份鉴定方式的res-auth元素和一个可选的引用共享范围的res-sharing-scope元素。
res-ref-name元素的值是EJB代码中使用的引用名称,相对于java:comp/env上下文,如值为jdbc/EmployeeAppDB的引用,实际上被视为java:comp/env/jdbc/EmployeeAppDB上下文。
res-type元素的值是引用的资源连接创建器的Java类型,如javax.sql.DataSource。
res-auth-type元素的值用于指定是否在EJB代码中包含登录资源的身份鉴定信息或是按照部署描述中的安全信息通过容器登录资源,如通过代码则值必须是Application,如通过容器则值必须是Container。
res-sharing-scope元素的值用于指定通过连接创建器引用创建的连接是否可以共享。其值可以是Shareable或是Unshareable,如未指定res-sharing-scope元素,则容器按照值为Shareble的情况进行处理。
由于在运行时,每个EJB组件的连接创建器引用的作用域仅存在于本组件内部,因此,不同EJB组件是访问不到其它组件中定义的连接创建器引用的,因此不同的EJB组件采用相同的连接创建器引用名字,不会发生冲突。
下面是EJB组件中声明连接创建器的部署描述文件的例子:
... <enterprise-beans> <session> ... <ejb-name>EmployeeService</ejb-name> <ejb-class>EmployeeServiceEJB</ejb-class> ... <resource-ref> <description> A data source for the database in which the EmployeeService enterprise bean will record a log of all transactions. </description> <res-ref-name>jdbc/EmployeeAppDB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> ... </session> </enterprise-beans> ...
下面是声明一个JMS消息系统连接创建器引用的例子:
... <enterprise-beans> <session> ... <resource-ref> <description> A queue connection factory used by the MySession enterprise bean to send notifications. </description> <res-ref-name>jms/qConnFactory</res-ref-name> <res-type>javax.jms.QueueConnectionFactory</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref> ... </session> </enterprise-beans> ...
对连接创建器引用的映射需要在apusic-application部署描述中使用resource-ref元素进行定义。
apusic-application部署描述中resource-ref元素的结构如下:
resource-ref元素结构
开发者需要将EJB组件中使用res-ref-name元素定义的引用名与实际的资源连接创建器的JNDI名进行映射。如上节中的例子,对应的apusic-application.xml部署描述文件有如下内容:
<apusic-application> ... <module> ... <ejb> ... <session ejb-name="EmployeeService"> ... <resource-ref> <res-ref-name>jdbc/EmployeeAppDB</res-ref-name> <jndi-name>jdbc/ConcreteDataSource</jndi-name> </resource-ref> ... </session> ... </ejb> ... </module> ... </apusic-application>
下面的例子演示如何在EJB组件代码中使用上面两节中定义的数据库连接的连接创建器创建JDBC连接:
public class EmployeeServiceBean implements SessionBean { EJBContext ejbContext; public void changePhoneNumber(...) { ... // obtain the initial JNDI context Context initCtx = new InitialContext(); // perform JNDI lookup to obtain resource manager // connection factory javax.sql.DataSource ds = (javax.sql.DataSource) initCtx.lookup("java:comp/env/jdbc/EmployeeAppDB"); // Invoke factory to obtain a connection. The security // principal is not given, and therefore // it will be defined in related deployment descriptor. java.sql.Connection con = ds.getConnection(); ... } }
可在连接创建器引用声明中出现的连接创建器引用包括如下类型:
-
JDBC
javax.sql.DataSource
-
JMS消息系统
javax.jms.QueueConnectionFactory
javax.jms.TopicConnectionFactory
-
Java Mail
javax.mail.Session
-
URL
java.net.URL
在EJB编程模型中,组件可通过某资源的被管理对象(如JMS消息服务中的队列或主题)的逻辑名字,进而取得对此被管理对象的引用。这一类逻辑名字,称为资源环境引用,属于EJB环境的一个组成部分。资源环境引用在EJB组件的部署描述中声明,通过这类引用,EJB组件即可适应不同的实际运行环境。
资源环境引用属于EJB环境项中的一个特殊组成部分,不通过env-entry元素进行声明,必须在ejb-jar中组件相关的部署描述的resource-env-ref元素进行声明;在部署到实际生产环境之前,还必须在apusic-application中组件相关的部署描述中使用resource-env-ref元素将引用与实际的被管理对象进行映射。
下图是ejb-jar中resource-env-ref元素的结构:
resource-env-ref元素结构
在ejb-jar中的resource-env-ref元素,包含一个可选的为此引用提供文档信息的description元素,一个声明引用名称的resource-env-ref-name元素和声明引用对象Java类型的resource-env-ref-type元素。
resource-env-ref-name是相对于java:comp/env上下文的一个JNDI名字。因此,如果在代码中使用了一个名为java:comp/env/jms/StockQueue的JMS队列的引用,则在resource-env-ref-name中的值应为jms/StockQueue,而不是java:comp/env/jms/StockQueue。
由于在运行时,每个EJB组件的资源环境引用的作用域仅存在于本组件内部,因此,不同EJB组件是访问不到其它组件中定义的资源环境引用的,因此不同的EJB组件采用相同的资源环境引用名字,不会发生冲突。
下面是在ejb-jar中声明资源环境引用的例子:
... <resource-env-ref> <description> This is a reference to a JMS queue used in the processing of Stock info </description> <resource-env-ref-name>jms/StockInfo</resource-env-ref-name> <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type> </resource-env-ref> ...
在完成对资源环境引用的声明之后,在部署到实际运行环境之前,开发者还需要将已声明的引用与实际的被管理对象进行映射。映射在整个应用的部署描述文件apusic-application.xml中进行,使用resource-env-ref元素。
apusic-applicatoin中的resource-env-ref元素结构如下图:
resource-env-ref元素结构
resource-env-ref元素中,必须包含一个resource-env-ref-name,其值为ejb-jar中对应的resource-env-ref元素中resource-env-ref-name元素的值;还必须包含一个jndi-name元素,此元素的值为被管理对象的JNDI名字。
上面例子对应的apusic-application中的resource-env-ref元素声明如下:
... <resource-env-ref> <resource-env-ref-name>jms/StockInfo</resource-env-ref-name> <jndi-name>jms/StockInfoQueue</jndi-name> </resource-env-ref> ...
本部署描述片断,将引用jms/StockInfo映射到一个名为jms/StockInfoQueue的JMS消息队列。
在EJB组件代码中,则可以使用JNDI的API,根据资源环境引用名查找并获取对实际运行环境中被管理对象的引用,如下例:
public class StockServiceBean implements SessionBean { public void processStockInfo(...) { ... // Obtain the default initial JNDI context. Context initCtx = new InitialContext(); // Look up the JMS StockQueue in the environment. Object result = initCtx.lookup( "java:comp/env/jms/StockQueue"); // Convert the result to the proper type. javax.jms.Queue queue = (javax.jms.Queue)result; } }
在EJB规范中,Bean管理事务的Session Bean和Message-driven Bean可以通过JNDI API查找“java:comp/UserTransaction”名字,取得对javax.transaction.UserTransaction对象的引用。
如下例:
public MySessionEJB implements SessionBean { ... public someMethod(){ Context initCtx = new InitialContext(); UserTransaction utx = (UserTransaction)initCtx.lookup( “java:comp/UserTransaction”); utx.begin(); ... utx.commit(); } ... }
public MySessionEJB implements SessionBean { SessionContext ctx; ... public someMethod(){ UserTransaction utx = ctx.getUserTransaction(); utx.begin(); ... utx.commit(); } ... }
相关推荐
### EJB环境配置详解 #### 一、环境配置 ##### 1.1 解压缩JBoss服务器 在开始配置EJB环境之前,首先需要准备好JBoss应用服务器。具体操作步骤如下: 1. **下载JBoss**: 如果还没有下载JBoss 4.2.2.GA版本,请先...
**EJB高级——资源管理与EJB环境** 在Java企业级开发中,Enterprise JavaBeans (EJB) 是一种核心组件,用于构建可扩展且可靠的分布式应用程序。本教程将深入探讨EJB中的资源管理和EJB环境,这对于理解如何高效地...
- **功能**:在EJB环境中,JNDI用于存储和查找命名对象,比如客户端代理对象。当客户端想要访问一个远程EJB时,它首先需要通过JNDI查找对应的客户端代理对象。例如,在这个例子中,客户端通过`TestHelloBeanStub`这...
### 在EJB环境下搭建CORBA开发环境的知识点详解 #### 一、背景与需求分析 随着互联网技术的迅速发展以及电信行业的不断壮大,各种网络设备的数量急剧增加,这对于网络运营商来说既是机遇也是挑战。面对多样化的...
全书共分16章,内容依次包含了Java EE概述、EJB基础、搭建EJB环境、会话bean、持久化实体、持久化实体管理器、对象关系映射、JPQL查询、消息驱动bean、事务、提高EJB 3.0性能、从Web层访问EJB 3和EJB安全、EJB和Web...
在EJB环境中,持久层的设计对于实现高效、灵活的数据管理至关重要。 在EJB中,持久层主要由以下组件构成: 1. **Entity Beans**:代表数据库中的表或记录。它们是应用程序中的业务对象,负责与数据库交互。在EJB 2...
7. **测试集成**:在测试Spring集成EJB的应用时,可以使用Spring TestContext Framework,它可以方便地模拟EJB环境,便于单元测试和集成测试的执行。 8. **部署与运行**:集成后的应用需要部署在支持EJB的Java EE...
- **容器外使用**:在非EJB环境中,需要手动管理实体Bean的生命周期,通常使用Spring框架来辅助管理。 ### 总结 EJB是Java平台上的企业级应用开发标准之一,通过提供一系列的服务和支持,极大地简化了复杂应用的...
在EJB环境中,JNDI主要应用于以下场景: 1. 客户端查找EJB:客户端通过JNDI查找服务器上部署的EJB组件,获取远程接口的引用,从而调用EJB方法。 2. EJB内部查找资源:EJB组件自身也可以使用JNDI查找和获取其他资源,...
综上所述,"第一个EJB访问数据库例子"这个项目将引导我们了解如何在EJB环境中设置和使用数据库连接,以及如何通过EJB组件执行SQL查询和操作。这个过程中,我们将涉及JDBC、JNDI、EJB组件类型、事务管理以及可能的JPA...
这些改变降低了EJB的学习曲线,使得开发者能更快地适应EJB环境。 3. **EJB核心规范**: ejb-3_0-fr-spec-ejbcore.pdf可能包含了EJB容器的核心功能,如会话bean、消息驱动bean、实体bean(包括容器管理的持久性 CMP ...
本文将详细讲解如何在Eclipse集成开发环境中配置EJB项目,特别适合初学者快速上手。 首先,我们需要理解EJB的基本概念。EJB是一种面向服务的组件模型,它定义了三种主要的角色:Session Beans(会话bean)、Entity ...
在这个"ejb+dao.rar_ejb"压缩包中,我们可以期待找到有关如何在EJB环境中使用DAO模式实现数据访问的示例代码和相关文档。 1. EJB(Enterprise JavaBeans)概念: EJB 是Java EE平台的核心部分,它提供了组件模型,...
在EJB环境中,JMS常被用来实现事件驱动架构,例如,一个bean可以发布消息,而其他bean则作为订阅者接收并处理这些消息。 综上所述,EJB规范是Java EE(现在称为Jakarta EE)的重要组成部分,它定义了一系列接口和...
jboss-4.2.2.GA.zip、jdk-1_5_0_14-windows-i586-p.exe、mysql-5.0.22-win32.zip几个构建EJB环境及开发工具包,方便用户直接调用。 三、ejb-3_0-fr-spec-ejbcore.pdf、ejb-3_0-fr-spec-persistence.pdf、ejb-3_0-fr...
总结来说,EJB3.0的第一个"Hello, World"项目展示了如何在EJB环境中创建、配置和使用无状态会话bean。通过这个项目,我们可以了解到EJB3.0的注解驱动特性和基本的项目结构。理解并掌握这些基础知识,将有助于进一步...
在EJB环境中,ASE通常作为后端数据库,支持EJB组件的数据存储和访问。 ASE的主要特性包括: 1. **高可用性**:通过镜像、复制和集群技术,ASE提供高可用性和灾难恢复能力。 2. **高性能**:利用优化的查询处理...