Java开发网 Java开发网
注册 | 登录 | 帮助 | 搜索 | 排行榜 | 发帖统计  

您没有登录

» Java开发网 » 技术文章库  

按打印兼容模式打印这个话题 打印话题    把这个话题寄给朋友 寄给朋友    该主题的所有更新都将Email到你的邮箱 订阅主题
flat modethreaded modego to previous topicgo to next topicgo to back
作者 如何在WEBSPERE5.0上进行EJB的移植(1.0-1.x or 1.x-2.0)
burning



发贴: 0
积分: 0
于 2003-01-05 00:05 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
3.8 Migrating from EJB 1.0 to EJB 1.1 or to EJB 2.0
This section provides instructions on how to migrate your enterprise beans from
EJB 1.0 to EJB 1.1 or to EJB 2.0. The main steps are:
 Migrating code from EJB 1.0 to EJB 1.1
 Converting projects from EJB 1.x to EJB 2.0
 Migrating code from EJB 1.x to EJB 2.0
3.8.1 Migrating code from EJB 1.0 to EJB 1.1
If you are migrating EJB 1.0 code to WebSphere Studio Application Developer,
there are some EJB 1.1 specification changes that may affect your code. You
may see some of the following validation errors or warnings due to EJB 1.1
changes:
 An enterprise bean cannot use the javax.jts.UserTransaction interface. Use
the new javax.transaction.UserTransaction interface instead.
 An entity bean cannot use the UserTransaction interface. This is not allowed
in 1.1.
 An entity bean must define FinderException in their throws clause of finder
methods.
 An enterprise bean cannot throw a java.rmi.RemoteException. It can throw a
javax.ejb.EJBException instead. But RemoteException must still be defined in
EJB home and remote interfaces (as required by RMI).
 You cannot use the finalize method.
 java.security.Identity is deprecated.
Chapter 3. Development tool migration 121
 Enterprise bean methods getCallerIdentity() and isCallerInRole(Identity) are
deprecated. Use getCallerPrincipal() and isCallerinRole(String roleName)
instead.
 getEnvironment is deprecated. Open ejb_jar.xml with EJB deployment
descriptor, Beans tab, and view environment variables (such as
TARGET_HOME_NAME)
String
homeName=aLink.getEntityContext().getEnvironment().getProperty("TARGET_HOME
_NAME");
if (homeName == null) homeName = "TARGET_HOME_NAME";
becomes:
Context env = (Context)(new InitialContext()).lookup("java:comp/env");
String homeName = (String)env.lookup("ejb10-properties/TARGET_HOME_NAME");
 CMP enterprise beans ejbCreate(...) methods should return the bean's
primary key class (instead of void).
 New HomeHandle interface, and EJBHome interface requires new
getHomeHandle() method:
public javax.ejb.HomeHandle getHomeHandle() { return null; }
You should consider enhancements to match EJB 1.1 changes such as:
 Entity bean primary keys can now be java.lang.String objects.
 Entity bean finder methods should define FinderException in their throws
clause.
 Entity bean finder methods return java.util.Collection.
 Check the format of your JNDI names (and local namespaces are now
supported).
 There are now security roles, and isolation levels are now defined at the
method level (they were defined at the EJB level for EJB 1.0).
You should review the EJB 1.1 changes in general to see what other application
changes are appropriate. For detailed information, refer to the following
publications and Web sites:
 Enterprise Java Beans Specification, Version 1.1, available at
http://java.sun.com/products/ejb/docs.html (see Section 1.3,
“Application compatibility”).
122 Migrating to WebSphere V5.0: An End-to-End Migration Guide
 The IBM WebSphere InfoCenter, found at
http://www.ibm.com/software/webservers/appserv/doc/v40/aes/infocente
r/index.html. Refer to the following sections:
– Transitioning to Version 4.0 (Click Application Server AE ->Migration ->
Transitioning to Version 4.0 and read the “Role-based security” section)
– Migrating to supported EJB specifications (Click Application Server AE
-> Migration -> 3.3 Migrating APIs and specifications -> 3.3.1
Migrating to supported EJB specifications)
– Migrating from Version 3.x (Click Application Server AE ->Migration ->
3.2 Migrating from previous products versions -> 3.2.2 Migrating
from Version 3.x)
 WebSphere Version 4 Application Development Handbook, SG24-6134,
available at
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246134.pdf (See the
section “Migrating 1.0 EJBs to 1.1 EJBs” on pages 267-268).
 Programming J2EE APIs with WebSphere Advanced, SG24-6124, available
at http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246124.pdf (See
the section on “EJB 1.1 code changes” on pages 113-114).
 EJB Development with VisualAge for Java for WebSphere Application Server,
SG24-6144, available at
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246144.pdf (See
Appendix Black Eye.
3.8.2 Converting projects from EJB 1.x to EJB 2.0
You can migrate your existing EJB 1.1 project to an EJB 2.0 project, or you can
keep both by creating a new EJB 2.0 project and then import the existing EJB 1.1
project JAR file into it, as follows:
 Right-click the 1.1 project and select Migrate -> J2EE version 1.2 to 1.3.
 Or, export the existing 1.1 project as an EJB JAR, create a new 2.0 project,
and then select File -> Import -> EJB JAR.
Note: Although the project is an EJB 2.0 project, the existing (or imported)
EJB 1.1 Container Managed Persistence (CMP) beans remain EJB 1.1 beans.
That is, the CMP beans are not converted to EJB 2.0.
3.8.3 Migrating code from EJB 1.x to EJB 2.0
EJB 2.0 beans are supported only in an EJB 2.0 project (although a 2.0 project
also supports 1.1 beans).
1. For any CMP 1.x bean, replace each CMP field with abstract getXXX and
setXXX methods. (Then the bean class needs to be abstract.)
2. For any CMP 1.x bean, change all occurrences of this.field = value to
setField(value) in ejbCreate() and elsewhere throughout the code.
3. For any CMP, create an abstract getXXX and setXXX method for the primary
key.
4. For any CMP 1.x finder, create an EJBQL (EJB Query Language) for each
finder.
5. For any CMP 1.x finder, return java.util.Collection instead of
java.util.Enumeration.
6. Update your exception handling (rollback behavior) for non-application
exceptions:
– Throw javax.ejb.EJBException instead of java.rmi.RemoteException to
report non-application exceptions.
– In EJB 2.0 and 1.1, all non-application exceptions thrown by the instance
result in the rollback of the transaction in which the instance executed, and
in discarding the instance.
– In EJB 1.0, the container would not roll back a transaction and discard the
instance if the instance threw the java.rmi.RemoteException.
7. Update your Exception handling (rollback behavior) for application
exceptions:
– In EJB 2.0 and 1.1, an application exception does not cause the container
to automatically roll back a transaction.
– In EJB 1.1, the container performs the rollback only if the instance have
invoked the setRollbackOnly() method on its EJBContext object.
– In EJB 1.0, the container was required to roll back a transaction when an
application exception was passed through a transaction boundary started
by the container.




flat modethreaded modego to previous topicgo to next topicgo to back
  已读帖子
  新的帖子
  被删除的帖子
Jump to the top of page

   Powered by Jute Powerful Forum® Version Jute 1.5.6 Ent
Copyright © 2002-2021 Cjsdn Team. All Righits Reserved. 闽ICP备05005120号-1
客服电话 18559299278    客服信箱 714923@qq.com    客服QQ 714923