IBM Rational Application Developer for Windows and Linux V6.0 迁移指南


目录

第 1 章 从 WebSphere Studio V5.1、5.1.1 或 5.1.2 进行迁移

  • 与 WebSphere Studio V5.1.x 的兼容性
  • 禁用与 WebSphere Studio V5.1.x 的兼容性
  • 更新 Web 项目中的 Faces 运行时资源
  • 更新 Web 项目中的 Faces Client 运行时资源
  • 迁移 Struts Web 项目
  • V6.0 中的调试器更改
  • WDO 到 SDO 的迁移
  • V6.0 中的 EGL 保留字
  • 第 2 章 更新 Rational Application Developer V6.0 中 Web 项目的 Faces 运行时资源

    第 3 章 更新 Rational Application Developer V6.0 中 Portlet 项目的 Faces 运行时资源

    第 4 章 迁移 J2EE 项目

  • 迁移安全 Web Service
  • J2EE 1.3 到 1.4 规范级别迁移
  • Enterprise JavaBean 项目(EJB 2.0 到 EJB 2.1)
  • Web 项目(Servlet 级别 2.3 到 Servlet 级别 2.4)
  • 连接器项目(JCA 1.0 到 JCA 1.5)
  • Web Service(J2EE 1.3 到 J2EE 1.4)
  • J2EE 1.2 到 1.4 规范级别迁移
  • 迁移 Enterprise JavaBeans 项目(EJB 1.1 到 EJB 2.1)
  • Web 项目(Servlet 级别 2.2 到 Servlet 级别 2.4)
  • Rational Application Developer V6.0 中 J2EE 迁移向导中的更改
  • 第 5 章 迁移到 Rational Application Developer V6.0 中的门户网站工具

  • 将 WebSphere Portal V4.2 Portlet 迁移到 V5.x
  • 更新 Portlet 项目中的 Faces 运行时资源
  • 第 6 章 WebSphere 测试环境的更改



    第 1 章 从 WebSphere Studio V5.1、5.1.1 或 5.1.2 进行迁移

    此文档提供了用于从 WebSphere(R) Studio Application Developer V5.1.x 迁移到 Rational(R) Application Developer V6.0 的指示信息。

    可以在下列主题中找到其它信息:

    有关使用 Rational Application Developer 的信息可以在联机帮助中找到。

    有关更新的文档,参阅 www.ibm.com/developerworks/rational

    有关从 WebSphere Studio 的先前版本迁移到 V5.x 或从 VisualAge(R) for Java(TM) 迁移到 WebSphere Studio 的信息,请访问 www.ibm.com/software/awdtools/studioappdev/support/ 并搜索《迁移指南》

    要从 WebSphere Studio V5.1.x 进行迁移:

    1. 在安装之前,阅读与 Eclipse V2.x 和 WebSphere Studio V5.1.x 的兼容性。注意,对于从 WebSphere Studio V5.1.2 的 Portal Toolkit V5.0.2.2 迁移的 Portlet 应用程序项目,不支持向后兼容性。
    2. 备份 WebSphere Studio V5.1.x 工作空间。
    3. 安装 Rational Application Developer。请参阅《安装指南》(install.html 文件),它在第一张产品 CD 的根目录中。
    4. 建议:缺省情况下,第一次启动 Rational Application Developer 时,会提示您确认您想要使用称为 rationalsdp6.0\workspace 的工作空间。也就是说,“工作空间启动程序”对话框指向的目录不是 WebSphere Studio 工作空间的目录。要在迁移旧的工作空间之前尝试使用新的环境,则在启动 Rational Application Developer 时接受缺省值或指定其它新目录名。例如,您可能会这样做以便您可以创建一个或两个测试项目、阅读新增内容(帮助 -> 欢迎)、学习一些新的教程(帮助 -> 教程库)或实践一些新的样本(帮助 -> 样本库)。
    5. 将项目迁移到 V6.0。可按如下所示将 WebSphere Studio V5.1.x 中创建的项目自动迁移到 V6.0:

      1. 迁移工作空间:当准备好迁移 V5.1.x 工作空间以长久使用它时,用旧的工作空间启动 Rational Application Developer。进度指示器确认正在自动迁移项目。

        注意:在工作空间迁移期间,将打开一个问题对话框,显示的消息为未能复原工作台布局。原因:复原工作台期间发生了问题。这些错误消息不会对工作空间的成功迁移产生任何影响。通过单击错误对话框中的详细信息按钮记下不能复原的透视图的名称,然后单击确定以关闭对话框。

        要复原透视图:

        1. 通过选择窗口 -> 关闭透视图来关闭透视图。
        2. 通过选择窗口 -> 打开透视图重新打开透视图。
        注:
        对于 WebSphere Studio V5.1.2 中使用 EGL Web 透视图的企业生成语言(EGL)项目:在 Rational Application Developer V6.0 中除去了此透视图。在 Rational Application Developer V6.0 中不需要此透视图就可以安全迁移所有 EGL 项目。如果使用 EGL Web 透视图,则执行以下操作:

        1. 关闭 EGL Web 透视图。
        2. 在“首选项”(窗口 -> 首选项)中启用 EGL 功能。有关启用 EGL 功能的详细信息,参阅联机帮助。
        3. 选择窗口 -> 打开透视图并选择 Web 透视图。
      2. 迁移从 SCM(源代码管理)系统装入的项目:存在于 SCM 系统中的来自 WebSphere Studio 5.1.x 的项目将在将把它装入到 Rational Application Developer 中时自动迁移到 V6.0。
      3. 使用“项目交换”迁移导入的项目:使用“项目交换”功能部件从 WebSphere Studio V5.1.2 或 V5.1.1 导出并导入到 Rational Application Developer V6.0 中的项目将自动迁移到 V6.0。 “项目交换”功能部件在 WebSphere Studio V5.1.2 中可用,对于 V5.1.1,它是一个可选插件。

      注意:

      要点:

    6. DB2(R) Net JDBC 驱动程序在 Rational Application Developer V6.0 中不受支持。如果使用 DB2 Net JDBC 驱动程序创建了 JDBC 连接,则在 Rational Application Developer V6.0 中将不能重新连接。将需要更改连接以使用其中一个受支持的 JDBC 驱动程序。有关在 V6.0 中受支持的 JDBC 驱动程序的更多信息,请参阅联机帮助。
    7. 如果从 WebSphere Studio Application Developer V5.1.x 迁移的 Web 或 XML 文件内容使用了 Shift_JIS 字符集并且包括供应商选择的字符,则必须改为指定 Windows-31J 字符集。
    8. 如果随 WebSphere Studio Application Developer V5.1.x 安装了任何供应商插件,则需要获取 V6.0 的相应插件并重新安装它们。
    9. 如果在安装 Rational Application Developer 时安装了任何后备级别 WebSphere V5.x 单元测试环境,并且如果您使用嵌入式消息传递服务,则通过安装 Rational Application Developer 提供的版本升级它。有关安装嵌入式消息传递服务的详细信息,请参阅《安装指南》
    10. 如果使用需要“代理控制器”的功能部件,则通过安装 Rational Application Developer 提供的版本升级它。有关详细信息,请参阅《安装指南》
    11. 要从 VisualAge Generator 迁移,在联机帮助中的 VisualAge Generator to EGL Migration Guide 帮助主题下面,请参阅 PDF 格式的 VisualAge Generator to Enterprise Generation Language (EGL) Migration Guide 中的 Installing and migrating 一节。最新的副本可从 http://www.ibm.com/developerworks/rational/library/egldoc.html 中获取。

    与 WebSphere Studio V5.1.x 的兼容性

    当在 Rational Application Developer 中第一次打开任何 WebSphere Studio V5.1.x 工作空间时,就会自动迁移它。一旦迁移了工作空间,就不再能够在 WebSphere Studio Application Developer 中打开它。但是,V6.0 工作空间中的项目仍然可以与 WebSphere Studio V5.1.x 共享,方法是使用源代码管理(SCM)系统(如 Rational ClearCase(R))、使用“项目交换”导入和导出项目以及导入归档和导出项目。要点:从 Portal Toolkit V5.0.2.2 迁移到 Rational Application Developer V6.0 中的门户网站工具的 Portlet 应用程序将不会向后兼容。

    注:
    以下内容不适用于 Portlet 应用程序项目。

    只要您执行下列任何操作,使用“项目交换”从 SCM 系统或者从另一个开发者装入到 V6.0 的现有 V5.1.x 项目就可与 V5.1.x 共享:

    当在 Rational Application Developer V6.0 工作空间中打开 V5.1.x 项目时,会自动在项目目录中创建 .compatibility 文件。在迁移项目资源时,Rational Application Developer 使用 .compatibility 文件跟踪这些资源的时间戳记。您不应编辑或删除它。

    有关禁用与 WebSphere Studio Application Developer V5.1.x 的兼容性的信息,参阅禁用与 WebSphere Studio V5.1.x 的兼容性

    Eclipse 注意事项

    此版本的 Rational Application Developer 基于 Eclipse V3.0。如果您开发您自己的插件,则在迁移之前应阅读对平台的更改。

    有关详细信息,参阅 Rational Application Developer V6.0 的安装位置的子目录 eclipse\readme 中的自述文件。该自述文件中有关迁移的几节内容包括:

    J2EE 项目兼容性

    WebSphere Studio V5.1.x 中创建的项目与 Rational Application Developer V6.0 的兼容性是通过迁移 V5.1.x 工作空间时自动添加至 .project 文件的元数据启用的。同样,如果在 Rational Application Developer V6.0 中创建新的 J2EE 1.2 或 1.3 模块或应用程序,构建元数据将自动添加至 .project 文件以便与 V5.1.x 兼容。不要直接编辑或删除此信息。

    注:
    因为在 WebSphere Studio Application Developer 中不能使用 V6.0 构建器,因此当在 V5.1.x 中使用在 V6.0 中创建的新的 J2EE 1.2 和 J2EE 1.3 模块或应用程序时,此兼容性元数据将导致显示或记录有关“缺少构建器”的消息。这些消息是正常的;可以忽略它们。

    只要存在此兼容性元数据,当将 Rational Application Developer V6.0 项目装回到 WebSphere Studio V5.1.x 中时,将会向您显示有关“缺少构建器”的消息。以下是“缺少构建器”消息的示例:

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !消息 跳过了项目 Test60EARWeb 的 com.ibm.wtp.j2ee.LibCopyBuilder 构建器。安装时缺少该构建器,或者它属于缺少或被禁用的项目性质。
    

    这些消息是正常的;可以忽略它们。当您确定不再需要使用 WebSphere Studio V5.1.x 中的给定项目时,可以通过禁用该项目的向后兼容性来停止消息。

    要点:在 V6.0 中创建的新 J2EE 1.2 或 1.3 规范项目与 WebSphere Studio V5.1.x 兼容,但一旦将项目装入到 WebSphere Studio,就需要执行一些手工步骤才能使用项目。这些步骤是必需的,原因是在 6.0 中创建的新的 J2EE 1.2 或 1.3 规范项目的运行时目标与 V5.1.x 中的目标服务器不直接向后兼容。在 V5.1.x 中装入新的 V6.0 项目之后的手工步骤如下所示:

    1. 对于具有 .classpath 文件的每个 J2EE 项目,打开 .classpath 文件。
    2. 从 .classpath 文件中删除以下类路径条目,然后保存并关闭文件。
    3. 确保在 J2EE 首选项页面中启用了确定目标服务器支持。选择窗口 -> 首选项 -> J2EE 并确认选择了“确定目标服务器支持”下面的启用确定目标服务器支持
    4. 右键单击项目并选择属性 -> J2EE
    5. 选择项目中运行时目标的对应目标服务器(例如,使用 JDK 1.4 运行时环境的 WebSphere Application Server V5.1),然后单击确定
    6. 您选择的目标服务器将与 Rational Application Developer V6.0 和 WebSphere Studio Application Developer V5.1.x 都兼容。当将更改落实到 SCM 系统中之后,通过使用 SCM 系统,J2EE 项目在 V5.1.x 与 V6.0 之间就是可互操作的了。
      注:
      如果在 Rational Application Developer V6.0 中又设置了目标服务器,则 J2EE 项目兼容性将会丢失,并且需要重新建立。

    UML 图兼容性

    WebSphere Studio Application Developer V5.1.x 中存在的 UML 图是向前兼容的,在 Rational Application Developer V6.0 中可以只读方式打开。在 V6.0 中,在 J2EE 项目结构迁移期间,J2EE 迁移向导自动迁移在 V5.1.x J2EE 项目中创建的 UML 图。迁移之后,就可以在 Rational Application Developer V6.0 中编辑 UML 图了。

    注:
    不能在 WebSphere Studio Application Developer V5.1.x 中打开迁移到 Rational Application Developer V6.0 或在 V6.0 中创建的工作空间中的 UML 图。

    禁用与 WebSphere Studio V5.1.x 的兼容性

    与 WebSphere Studio Application Developer V5.1.x 的兼容性可从在 Rational Application Developer V6.0 中创建的企业应用程序项目中或从较早版本的 WebSphere Studio 迁移的企业应用程序项目中完全除去。仅当您确定企业应用程序项目不应再与 V5.1.x 可互操作或兼容时,才应禁用与 WebSphere Studio V5.1.x 的兼容性。

    要除去与 WebSphere Studio Application Developer V5.1.x 的兼容性:

    1. 右键单击企业应用程序项目并从弹出菜单中选择除去兼容性菜单选项。
    2. 将出现一个对话框,让您确认是否除去企业应用程序项目及该项目下嵌套的所有模块和实用程序项目的向后兼容性。
    3. 单击以继续“除去兼容性”操作。

    一旦运行了“除去兼容性”操作,企业应用程序项目和该企业应用程序项目下嵌套的所有模块和实用程序项目就不再与 WebSphere Studio Application Developer V5.1.x 向后兼容。


    更新 Web 项目中的 Faces 运行时资源

    已经对 Rational Application Developer V6.0.1 更新了 WebSphere Studio Application Developer V5.1.x 中最初提供的 JavaServer Faces 运行时资源。如果想要继续在使用此先前产品版本创建的 Web 项目上进行开发,建议您将 Faces 运行时资源更新为最新级别。

    在 Rational Application Developer V6.0.1 中,当导入 Web 项目或者打开包含过时资源的工作空间时,就会自动更新 Faces 运行时资源。在 Rational Application Developer V6.0.1 中,导入来自 WebSphere Studio Application Developer V5.1.x 的 Web 项目或者打开来自 V5.1.x 的工作空间之后,将提示您将 Faces 运行时资源更新为最新级别。

    自动更新运行时资源

    自动更新 Web 项目的 Faces 运行时资源:

    1. 导入一个包含来自于 WebSphere Studio Application Developer V5.1.x 的 Faces Client 内容的 Web 项目(或工作空间)。“项目迁移”窗口将打开。
      注:
      如果“项目迁移”窗口未打开,则可能已经禁用了自动构建首选项设置。在“项目资源管理器”中,右键单击 Web 项目并选择构建 -> 项目;重建项目的过程将打开“项目迁移”窗口。
    2. 如果工作空间中具有其它包含 Faces 内容的 Web 项目,则选择将此选项应用于需要升级的其它任何项目,就会更新所有 Web 项目。
    3. 单击下列其中一项:
    注:
    如果您创建了包含 Faces Client 组件的 Faces JSP,则必须单独将 Faces Client 组件运行时资源更新为最新级别。请参阅更新 Web 项目中的 Faces Client 运行时资源

    手工更新运行时资源

    手工更新 Web 项目的 Faces 运行时资源:

    1. 将具有 Faces 内容的现有 Web 项目导入到 Rational Application Developer V6.0.1 工作空间中。
    2. 创建一个新的名为 JSF601 的 Web 项目(或者,如果正在使用 EGL,则创建一个新的 EGL Web 项目)。仅将此项目用作最新运行时资源的源;在完成更新之后可以删除它。
    3. 在“项目资源管理器”中,右键单击 JSF601 项目并从菜单中选择属性
    4. 单击 Web 项目功能部件并选择添加 Faces 基本组件添加 Faces Client 框架,然后单击确定
    5. 如果正在使用 EGL,则按如下所示创建一个 JSF 页文件:

      1. 右键单击新的 EGL Web 项目的 WebContent 文件夹。
      2. 选择新建 -> 其它 -> Faces JSP 文件
      eglintdebug.jareglintdebugsupport.jar 文件便被添加到项目中。
    6. 对于想要更新的每个现有 Faces 项目,执行下列操作:

      1. 在“项目资源管理器”中展开现有项目以显示 WebContent/WEB-INF/lib/ 文件夹中的文件。找到此目录中的下列任何 JAR 文件并删除它们:
        • eglintdebug.jar(仅适用于 EGL)
        • eglintdebugsupport.jar(仅适用于 EGL)
        • fda.jar(仅适用于 EGL)
        • fdaj.jar(仅适用于 EGL)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. 找到文件 WebContent/WEB-INF/faces-config.xml 并打开它。如果下列元素不存在,则将它们添加到此配置文件中:
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
      3. 对于删除的任何 JAR 文件,复制 JSF601 项目的 WebContent/WEB-INF/lib 目录中的同名 JAR 文件并将其粘贴到原始项目中的同一位置。某些配置并不需要在项目中有所有这些 JAR 文件;如果原始项目没有某个 JAR 文件,则不要复制它。
      4. 在原始项目中打开 web.xml 部署描述符并将下列内容添加至配置:
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>
        	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
      5. 如果原始项目使用 WebSphere 数据对象(WDO)来进行任何数据访问,则执行下列附加步骤:

        1. 在原始项目中,单击文件 -> 新建 -> Faces JSP 文件以创建新的临时 Faces JSP 文件。
        2. 将关系记录列表组件从选用板的“数据”抽屉拖到该页面中。
        3. 选取任何连接和数据源并单击完成。所选数据不重要。此过程将生成任何必需的配置以在此项目中继续使用 WDO。
        4. 删除临时 JSP 文件。
      6. 如果正在使用 EGL,则右键单击每个 EGL Web 项目的名称并单击生成;接着,如果不想自动构建项目,则单击项目 -> 全部构建
    7. 删除 JSF601 Web 项目。

    更新 Web 项目中的 Faces Client 运行时资源

    已经对 Rational Application Developer V6.0.1 更新了 WebSphere Studio Application Developer V5.1.x 中最初提供的 JavaServer Faces Client 运行时资源。如果想要继续在使用此先前产品版本创建的 Web 项目上进行开发,建议您将 Faces Client 运行时资源更新为最新级别。

    在 Rational Application Developer V6.0.1 中,当导入 Web 项目或者打开包含过时资源的工作空间时,就会自动更新 Faces Client 运行时资源。在 Rational Application Developer V6.0.1 中,导入来自 WebSphere Studio Application Developer V5.1.x 的 Web 项目或者打开来自 V5.1.x 的工作空间之后,将提示您将 Faces Client 运行时资源更新为最新级别。

    自动更新运行时资源

    自动更新 Web 项目的 Faces Client 运行时资源:

    1. 导入一个包含来自于 WebSphere Studio Application Developer V5.1.x 的 Faces Client 内容的 Web 项目(或工作空间)。“项目迁移”窗口将打开。
      注:
      如果“项目迁移”窗口未打开,则可能已经禁用了自动构建首选项设置。在“项目资源管理器”中,右键单击 Web 项目并选择构建 -> 项目;重建项目的过程将打开“项目迁移”窗口。
    2. 如果工作空间中具有其它包含 Faces Client 内容的 Web 项目,则选择将此选项应用于需要升级的其它任何项目,就会更新所有 Web 项目。
    3. 单击下列其中一项:
    4. 从 Web 项目中的 Java 资源 -> JavaSource 文件夹中,删除命名约定为 com.ibm.dynwdo4jsmediators.<client-data-name> 的所有客户机数据介体类包。不要删除名为 com.ibm.dynwdo4jsmediators 的包。此包包含项目中客户机数据的元数据(ecore 和 emap 文件),它们将用来重新生成介体。
    5. 从 Web 项目中的 Java 资源 -> JavaSource 文件夹中,打开 OdysseyBrowserFramework.properties 文件并删除 EMAP_FILESECORE_FILES 的条目。
    6. 对于“客户机数据”视图中的每个数据对象:
      1. 右键单击并选择配置
      2. 高级选项卡上,单击从服务器端的数据重新生成以便为数据对象重新生成所有介体。

    手工更新运行时资源

    手工更新 Web 项目的 Faces Client 运行时资源:

    1. 完成更新 Web 项目中的 Faces 运行时资源中的手工更新运行时资源步骤。
    2. 完成上面的自动更新运行时资源这一节中的步骤 4 到步骤 6。

    当将包含 Faces Client 组件的项目的目标服务器从 WebSphere Application Server V5.1 更改为 V6.0 时可能会产生问题。

    当将包含 Faces Client 组件的项目的目标服务器从 WebSphere Application Server V5.1 更改为 V6.0 时可能会产生两个问题:

    升级到自动差别处理程序和处理器

    现在会自动生成差别处理器和处理程序。如果在 WebSphere Studio V5.1.x 中为 Faces Client 组件编写了差别处理程序和处理器,则建议您废弃该代码并使用自动生成的处理器和处理程序:

    1. 对 Web 项目中每个客户机数据对象生成新的差别处理程序和处理器。
      1. 选择客户机数据对象,右键单击并选择配置
      2. 高级选项卡上,单击全部重新生成
    2. 除去为调用差别处理器和处理程序而编写的代码,原因是会自动调用生成的处理器和处理程序。以前,使用此代码的典型示例是用于“命令按钮”组件的“命令”事件,如下所示:
      String Diff = getClientData1().getDiffStr();
      if (DiffProcessor.Synch(getRoot(), Diff) == true)
       return "";
      return "failure";
      
    3. 从 Web 项目中除去与您创建的旧的定制处理程序和处理器对应的文件。

    保留为 V5.1.x 编写的定制差别处理程序和处理器

    虽然建议不要这么做,但是如果您决定需要保留来自 V5.1.x 的定制差别处理程序和处理器,则需要对它们进行修改才能在 V6.0 中工作,这是因为 DiffHandler 接口和 DiffInfo 类已经更改。

    在 V6.0 中对 Faces Client 组件的更改


    迁移 Struts Web 项目

    对于在 WebSphere Studio V5.1.x 中创建的 Struts Web 项目,必须对 Web 项目的部署描述符稍加修改以便在 WebSphere Application Server V6.0 上运行 EAR 项目。您可能还希望以手工方式将现有的 Struts 1.0.2 或 Struts 1.1 Beta(2 或 3)Web 项目转换为 Struts 1.1。

    修改现有 Struts Web 项目的部署描述符

    当在 WebSphere Studio V5.x 中创建了 Struts 项目时,Web 项目的部署描述符中的 config 参数(<param-name>config</param-name>)设置为 WEB-INF/struts-config.xml。WebSphere Application Server V6.0 要求此参数中存在前导“/”。如果在 WebSphere Application Server V6.0 上运行一个在 WebSphere Studio V5.1.x 中创建的 Struts Web 项目,则您在启动 EAR 项目时可能会接收到 java.net.MalformedURLException 异常。

    注:
    当创建新的 Struts 项目时,Rational Application Developer V6.0 将添加“/”;但是,当从 WebSphere Studio V5.1x 迁移时,必须手工添加“/”。

    在 V6.0 中,遵循下列步骤来更正在 WebSphere Studio V5.1.x 中创建的 Struts Web 项目的部署描述符:

    1. 在“项目资源管理器”中打开 Struts Web 项目。
    2. 在“项目资源管理器”中双击该 Web 项目的 Web 部署描述符文件。Web 部署描述符编辑器将打开。
    3. 单击源代码选项卡以打开“源代码”页面。
    4. <param-value>WEB-INF/struts-config.xml</param-value> 这一行(它位于 <servlet></servlet> 标记中)

      更改为

      <param-value>/WEB-INF/struts-config.xml</param-value>

    5. 保存 Web 部署描述符

    当重新启动 EAR 项目时不应发生 java.net.MalformedURLException 异常。

    将 Struts 1.1 Beta Web 项目转换为 Struts 1.1

    在 WebSphere Studio V5.1.x 中,Struts 运行时库将从 V5.0.x 中的 Struts 1.1 Beta(2 或 3)升级到 Struts 1.1(最终)。如果您想将现有 Struts 1.1 Beta(2 或 3)Web 项目转换为 Struts 1.1(最终),则可以手工转换它们。(注意:不需要将 Struts 1.1 Beta(2 或 3)项目转换为 Struts 1.1。)

    要将 Struts 1.1 Beta(2 或 3)项目转换为 Struts 1.1,执行下列操作:

    1. 将 Struts 1.1 Beta 项目装入到 Rational Application Developer V6.0 工作空间中。
    2. 创建一个新的 Struts 1.1 Web 项目,例如,名称为 Struts11。创建此临时项目以便能够很方便地访问当您转换实际项目时将需要的 Struts 1.1 运行时文件。完成后可以删除此项目。
    3. 对于想要转换为 Struts 1.1 的每个 Struts 1.1 Beta 项目,执行下列操作:
      1. 从项目的 Web Content/WEB-INF/lib 目录中删除下列 JAR 文件:
        • commons-*.jar。
        • struts.jar。
      2. 将下列 JAR 文件从 Struts11/WebContent/WEB-INF/lib 目录复制到项目的 Web Content/WEB-INF/lib 目录中:
        • commons-*.jar。
        • struts.jar。
      3. 从项目的 Web Content/WEB-INF 目录中删除下列“标记库描述符”(TLD)文件:struts-*.tld。
      4. 将下列 TLD 文件从 Struts11/WebContent/WEB-INF 目录复制到项目的 Web Content/WEB-INF 目录中:struts-*.tld。

    将 Struts 1.0.2 Web 项目转换为 Struts 1.1

    在 WebSphere Studio V5.1.x(和 V5.0.x)中,当将 Struts 支持添加至 Web 项目时,您可以选择 Struts 1.0.2。如果您想将现有 Struts 1.0.2 Web 项目转换为 Struts 1.1,则可以手工转换它们。(注意:不需要将 Struts 1.1 Beta(2 或 3)项目转换为 Struts 1.1。)

    要将 Struts 1.0.2 项目转换为 Struts 1.1,执行下列操作:

    1. 将 Struts 1.0.2 项目装入到 Rational Application Developer V6.0 工作空间中。
    2. 创建一个新的 Struts 1.1 Web 项目,例如,Struts11。创建此临时项目以便能够很方便地访问当您转换实际项目时将需要的 Struts 1.1 运行时文件。完成后可以删除此项目。
    3. 对于想要转换为 Struts 1.1 的每个 Struts 1.0.2 项目,执行下列操作:
      1. 从项目的 Web Content/WEB-INF/lib 目录中删除 struts.jar 文件。
      2. 将下列 JAR 文件从 Struts11/WebContent/WEB-INF/lib 目录复制到项目的 Web Content/WEB-INF/lib 目录中:
        • commons-*.jar。
        • struts.jar。
        • jarkarta-oro.jar。
      3. 从项目的 Web Content/WEB-INF 目录中删除下列“标记库描述符”(TLD)文件:struts-*.tld。
      4. 将下列 TLD 文件从 Struts11/WebContent/WEB-INF 目录复制到项目的 Web Content/WEB-INF 目录中:struts-*.tld。

    V6.0 中的调试器更改

    Rational Application Developer V6.0 中的调试工具有许多更改。您需要知道这些更改以便将这些工具与项目后续迁移配合使用。并且可能需要更改或复原一些设置。

    迁移工作空间和启动配置

    当在 Rational Application Developer V6.0 中打开 WebSphere Studio Application Developer 中的 V5.1.x 工作空间时,将不会自动迁移以下与该工作空间相关联的调试器启动配置:

    调试视图

    “存储器”视图和“存储器映射”视图不再存在。它们已替换为“内存”视图和“内存呈示”视图。

    XSLT 调试器

    XSLT 调试器在 V6.0 中已更改,它的许多视图和操作也已发生了很大的变化。有关更多信息,请参阅信息中心中的 XSLT 调试器文档。

    XSLT 调试器中的其中一个最重大的变化是它对 JRE 的依赖项是随 Rational Application Developer V6.0 安装的。如果从 WebSphere Studio Application Developer V5.1.x 迁移工作空间,则将需要修改已安装 JRE 以指向正确的位置,然后才能对它启动 XSLT 调试会话。为此,可以执行下列其中一个操作:


    WDO 到 SDO 的迁移

    如果在目标为使用 WebSphere 数据对象(WDO)关系记录或关系记录列表的 WebSphere Application Server V5.1 的 Web 项目中创建了代码,则当您将这些应用程序的目标确定为 WebSphere Application Server V6.0 时,现在将使用服务数据对象(SDO)关系记录和关系记录列表。将应用程序的目标服务器从 WebSphere Application Server V5.1 更改为 WebSphere Application Server V6.0 时,会自动进行从 WDO 到 SDO 的迁移。

    可用两种方法更改目标服务器:

    可在 Rational Application Developer 的联机帮助中找到有关更改目标服务器和使用 J2EE 迁移向导的帮助主题。

    兼容性注意事项

    从 WDO 迁移到 SDO 可能会发生类型冲突错误

    在将利用 WDO 的项目迁移到基于 SDO 的项目之后,如果将 SDO 数据添加至具有现有 WDO 数据的现有 JSP 页,则可能会发生类型冲突错误。产生这种问题的原因是混合出现了现有 WDO 访问 bean 和独立的 SDO API。例如,可在 JSP 的 Java 源文件中看到下列编译错误:

    The import com.ibm.websphere.sdo.mediator.exception.MediatorException collides with another imported type
    

    这些类型冲突错误可按如下所述更正:

    1. 从 Java 源文件中除去冲突的 import 语句。对于上面的示例,从源文件中除去以下 import 语句:
      import com.ibm.websphere.wdo.mediator.exception.MediatorException;
      
    2. 将引用该类型的 Java 源文件修改为使用标准类名。根据上面的示例,必须将类型 MediatorException 更改为 com.ibm.websphere.wdo.mediator.exception.MediatorException。例如,必须将如下源代码:
      catch ( MediatorException e1 ) {
      

      更改为:

      catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
      

    将目标服务器从 V5.1 更改为 V6.0(WDO 到 SDO)之后对 Web 项目的更改

    当目标服务器从 V5.1 更改为 V6.0 时,将自动进行下列更改:

    将服务器目标从 V6.0 更改为 V5.1(SDO 到 WDO)之后对 Web 项目的更改

    当目标服务器从 V6.0 更改为 V5.1 时,将自动进行下列更改:

    将应用程序的 J2EE 级别从 1.3 更改 1.4 之后对 Web 项目的更改

    除通过将服务器目标更改为 WebSphere Application Server V6.0 从 WDO 迁移到 SDO 时发生的更改之外,将应用程序的 J2EE 规范级别从 1.3 更改为 1.4 还会将 JavaServer Pages(JSP)中的所有标记库(taglib)引用从使用 WDO JSTL 1.0 标记库更新为使用 SDO JSTL 1.1/jsp 2.0 标记库。下表显示从 J2EE 1.3 移至 J2EE 1.4 时 JSP 标记库引用中的更改。


    表 1. J2EE 1.3 和 J2EE 1.4 中的 JSP 标记库引用。

    J2EE 1.3 标记库(WDO) J2EE 1.4 标记库(SDO)
    http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core
    http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core
    http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt
    http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml
    http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql

    V6.0 中的 EGL 保留字

    Rational Application Developer 中有一些企业生成语言(EGL)的新保留字。

    这些新保留字列示如下:

    WebSphere Studio V5.1.x 中使用这些词语作为变量名或部件名的 EGL 程序,在 V6.0 工作空间中导入并构建这些 EGL 程序时会有如下消息:IWN.SYN.2002.e 39/2 Syntax error on input "variableName"。可以通过重命名变量来更正问题。


    第 2 章 更新 Rational Application Developer V6.0 中 Web 项目的 Faces 运行时资源

    已经对 Rational Application Developer V6.0.1 更新了 Rational Application Developer V6.0 中最初提供的 JavaServer Faces 和 Faces Client 运行时资源。如果想要继续在使用此先前产品版本创建的 Web 项目上进行开发,建议您将 Faces 和 Faces Client 运行时资源更新为最新级别。

    在 Rational Application Developer V6.0.1 中,当导入 Web 项目或者打开包含过时的 Faces 或 Faces Client 运行时资源的工作空间时,就会自动更新 Faces 和 Faces Client 运行时资源。在 Rational Application Developer V6.0.1 中,导入来自 Rational Application Developer V6.0 的 Portlet 项目或者打开来自 V6.0 的工作空间之后,将提示您将这些运行时资源更新为最新级别。

    自动更新运行时资源

    自动更新 Web 项目的 Faces 和 Faces Client 运行时资源:

    1. 导入一个包含来自于 Rational Application Developer V6.0 的 Faces 或 Faces Client 内容的 Web 项目(或工作空间)。“项目迁移”窗口打开。
      注:
      如果“项目迁移”窗口未打开,则可能已经禁用了自动构建首选项设置。在“项目资源管理器”中,右键单击 Web 项目并选择构建 -> 项目;重建项目的过程将打开“项目迁移”窗口。
    2. 如果工作空间中具有其它包含 Faces 或 Faces Client 内容的 Web 项目,则选择将此选项应用于需要升级的其它任何项目,就会更新所有 Web 项目。
    3. 单击下列其中一项:

    手工更新运行时资源

    手工更新 Web 项目的 Faces 和 Faces Client 运行时资源:

    1. 创建一个新的名为 JSF601 的 Web 项目(或者,如果正在使用 EGL,则创建一个新的 EGL Web 项目)。仅将此项目用作最新运行时资源的源;在完成更新之后可以删除它。
    2. 在“项目资源管理器”中,右键单击 JSF601 项目并从菜单中选择属性
    3. 单击 Web 项目功能部件并选择添加 Faces 基本组件添加 Faces Client 框架,然后单击确定
    4. 如果正在使用 EGL,则按如下所示创建一个 JSF 页文件:

      1. 右键单击新的 EGL Web 项目的 WebContent 文件夹。
      2. 选择新建 -> 其它 -> Faces JSP 文件
      eglintdebug.jareglintdebugsupport.jar 文件便被添加到项目中。
    5. 对于想要更新的每个现有 Faces 项目,执行下列操作:

      1. 在“项目资源管理器”中展开现有项目以显示 WebContent/WEB-INF/lib/ 文件夹中的文件。找到此目录中的下列任何 JAR 文件并删除它们:
        • eglintdebug.jar(仅适用于 EGL)
        • eglintdebugsupport.jar(仅适用于 EGL)
        • fda6.jar(仅适用于 EGL)
        • fdaj6.jar(仅适用于 EGL)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. 对于删除的任何 JAR 文件,复制 JSF601 项目的 WebContent/WEB-INF/lib 目录中的同名 JAR 文件并将其粘贴到原始项目中的同一位置。某些配置并不需要在项目中有所有这些 JAR 文件;如果原始项目没有某个 JAR 文件,则不要复制它。
      3. 如果正在使用 EGL,则右键单击每个 EGL Web 项目的名称并单击生成;接着,如果不想自动构建项目,则单击项目 -> 全部构建
    6. 删除 JSF601 Web 项目。

    第 3 章 更新 Rational Application Developer V6.0 中 Portlet 项目的 Faces 运行时资源

    已经对 Rational Application Developer V6.0.1 更新了 Rational Application Developer V6.0 中最初提供的 JavaServer Faces 和 Faces Client 运行时资源。如果想要继续在使用此先前产品版本创建的 Portlet 项目上进行开发,建议您将 Faces 和 Faces Client 运行时资源更新为最新级别。

    在 Rational Application Developer V6.0.1 中,当导入 Portlet 项目或者打开包含过时的 Faces 或 Faces Client 运行时资源的工作空间时,就会自动更新 Faces 和 Faces Client 运行时资源。在 Rational Application Developer V6.0.1 中,导入来自 Rational Application Developer V6.0 的 Portlet 项目或者打开来自 V6.0 的工作空间之后,将提示您将这些运行时资源更新为最新级别。

    自动更新运行时资源

    自动更新 Portlet 项目的 Faces 和 Faces Client 运行时资源:

    1. 导入一个包含来自于 Rational Application Developer V6.0 的 Faces 或 Faces Client 内容的 Portlet 项目(或工作空间)。“项目迁移”窗口打开。
      注:
      如果“项目迁移”窗口未打开,则可能已经禁用了自动构建首选项设置。在“项目资源管理器”中,右键单击 Portlet 项目并选择构建 -> 项目;重建项目的过程将打开“项目迁移”窗口。
    2. 如果工作空间中具有其它包含 Faces 或 Faces Client 内容的 Portlet 项目,则选择将此选项应用于需要升级的其它任何项目,就会更新所有 Portlet 项目。
    3. 单击下列其中一项:
    4. 要更新特定于 Portlet 的 Faces 运行时资源 jsf-portlet.jar 和 jsf-wp.jar,您需要遵循下面的手工更新步骤。

    手工更新运行时资源

    手工更新 Portlet 项目的 Faces 和 Faces Client 运行时资源:

    1. 创建一个新的称为 JSFP601 的 Portlet 项目。仅将此项目用作最新运行时资源的源;在完成更新之后可以删除它。
    2. 在“项目资源管理器”中,右键单击 JSFP601 项目并从菜单中选择属性
    3. 单击 Web 项目功能部件并选择为 Portlet 项目添加 Faces Client 框架,然后单击确定
    4. 对于想要更新的每个现有 Faces Portlet 项目,执行下列操作:

      1. 在“项目资源管理器”中展开现有项目以显示 WebContent/WEB-INF/lib/ 文件夹中的文件。找到此目录中的下列任何 JAR 文件并删除它们:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. 对于删除的任何 JAR 文件,复制 JSFP601 项目的 WebContent/WEB-INF/lib 目录中的同名 JAR 文件并将其粘贴到原始项目中的同一位置。某些配置并不需要在项目中有所有这些 JAR 文件;如果原始项目没有某个 JAR 文件,则不要复制它。
        • 如果 Portlet 项目使用 IBM(R) Portlet API 或人员链接组件,则将 jsf-wp.jar 文件复制到原始项目中。
        • 如果复制 odc-jsf.jar 文件,则还应复制 odc-jsf-portlet.jar 文件。
    5. 删除 JSFP601 Portlet 项目。

    第 4 章 迁移 J2EE 项目

    在 Rational Application Developer V6.0 中,已更新了 J2EE 迁移向导来将 J2EE 项目迁移到 J2EE 1.4 规范级别。J2EE 迁移向导支持将所有 J2EE 模块类型从 J2EE 1.2 和 1.3 规范迁移到 J2EE 1.4 规范级别。

    有关将 J2EE 1.3 和 1.2 规范级别工件迁移到 J2EE 1.4 规范级别的详细信息,请参阅 J2EE 1.3 到 1.4 规范级别迁移J2EE 1.2 到 1.4 规范级别迁移

    注:
    在使用 J2EE 迁移向导之前,强烈建议您执行下列步骤:

    可按如下所示访问 J2EE 迁移向导:

    1. 在 J2EE 透视图的 J2EE 层次结构视图中,右键单击想要迁移的企业应用程序项目。
    2. 从弹出菜单中选择迁移 -> J2EE 迁移向导
    3. 继续迁移过程之前,阅读 J2EE 迁移向导欢迎页面上的指示信息。

    注意:

    有关使用 J2EE 迁移向导的完整详细信息,请参阅联机帮助。向导的更改在 Rational Application Developer V6.0 中 J2EE 迁移向导中的更改中作了描述。

    有关迁移到 J2EE 1.4 时对 J2EE 1.3 和 1.2 规范级别工件的更改的详细信息,参阅 J2EE 1.3 到 1.4 规范级别迁移J2EE 1.2 到 1.4 规范级别迁移


    迁移安全 Web Service

    将 Web Service 从 J2EE 1.3 迁移到 J2EE 1.4 时,J2EE 迁移向导将不会迁移安全 Web Service。安全 Web Service 的迁移需要手工步骤来完成。

    在 J2EE 迁移之后,必须按如下所示手工将安全绑定和扩展文件迁移到 J2EE 1.4:

    1. 双击 webservices.xml 文件以打开 Web Service 编辑器。
    2. 选择绑定配置选项卡以编辑绑定文件。
    3. 在新的部分请求消费者绑定配置详细信息响应产生者绑定配置详细信息下面添加所有必需的绑定配置。
    4. 选择扩展选项卡以编辑扩展文件。
    5. 在新的部分请求消费者服务配置详细信息响应产生者服务配置详细信息下面添加所有必需的扩展配置。
    6. 保存并退出编辑器。

    J2EE 1.3 到 1.4 规范级别迁移

    可将 J2EE 项目从 J2EE 1.3 迁移到 J2EE 1.4 规范级别。本节描述,对于每种类型的 J2EE 项目,由 J2EE 迁移向导从 J2EE 1.3 迁移到 J2EE 1.4 的工件。

    Enterprise JavaBean 项目(EJB 2.0 到 EJB 2.1)

    J2EE 迁移向导支持将企业 bean 部署描述符从 J2EE 1.3 规范级别 EJB 资源迁移到 J2EE 1.4。将无状态会话 bean 和消息驱动的 Bean 迁移到 J2EE 1.4。

    迁移会话 bean

    通过对无状态会话 bean 设置服务端点接口,J2EE 迁移向导将 J2EE 1.3 中的 EJB 项目的 webservices.xml 描述符中定义为服务端点接口(SEI)的无状态会话 bean 迁移到 J2EE 1.4 规范级别。

    如果要将无状态会话 bean 用作 Web Service 端点,则 J2EE 1.4 规范需要对该会话 bean 定义 SEI。在迁移 EJB JAR 文件期间,EJB 项目中的所有会话 bean 都将获得服务端点,该服务端点被设置为在 EJB 项目的 webservices.xml 描述符中使用的名称。以下是在迁移到 J2EE 1.4 规范级别前后 EJB 项目的元数据的外观的示例。

    J2EE 1.3 中的 EJB 项目:迁移前将无状态会话 bean 用作 Web Service 端点接口的 webservices.xml 描述符

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN"
    "http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
       <webservices id="WebServices_1084831328093">
          <webservice-description id="WebServiceDescription_1084831328093">
             <webservice-description-name>EchoEJBService</webservice-description-name>
             <wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
             <jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
             <port-component id="PortComponent_1084831328103">
                <port-component-name>EchoEJB</port-component-name>
                <wsdl-port id="WSDLPort_1084831328103">
                   <namespaceURI>http://test</namespaceURI>
                   <localpart>EchoEJB</localpart>
                </wsdl-port>
                <service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
                <service-impl-bean id="ServiceImplBean_1084831328103">
                   <ejb-link>EchoEJB</ejb-link>
                </service-impl-bean>
             </port-component>
          </webservice-description>
       </webservices>
    

    前面的示例中,在迁移之前 J2EE 1.3 规范级别的 webservices 描述符中,<service-endpoint-interface><service-impl-bean> 标记将无状态会话 bean“EchoEJB”定义为服务端点。

    J2EE 1.4 中的 EJB 项目:相同无状态会话 bean“EchoEJB”的 EJB 部署描述符,该会话 bean 具有由迁移过程创建的服务端点接口

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar>
    <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
    	<display-name>
    	EchoEJBProject</display-name>
    	<enterprise-beans>
    		<session id="EchoEJB">
    			<ejb-name>EchoEJB</ejb-name>
    			<home>test.EchoEJBHome</home>
    			<remote>test.EchoEJB</remote>
    			<service-endpoint>test.EchoEJB</service-endpoint>
    			<ejb-class>test.EchoEJBBean</ejb-class>
    			<session-type>Stateless</session-type>
    			<transaction-type>Container</transaction-type>
    		</session>
    	</enterprise-beans>
    </ejb-jar>
    

    前面示例中的 <service-endpoint> 标记将“EchoEJB”定义为迁移之后 J2EE 1.4 规范级别中的服务端点。

    迁移消息驱动的 bean

    J2EE 迁移向导支持将 EJB 2.0 消息驱动的 Bean 迁移到 EJB 2.1 消息驱动的 Bean。

    EJB 2.0 中引进了消息驱动的 Bean 以支持处理来自 Java 消息服务(JMS)的异步消息。EJB 2.1 规范扩展了消息驱动的 Bean 的定义,以便它不仅可以支持 JMS,还可以支持任何消息传递系统。

    注:
    对于已从 EJB 2.0 规范级别迁移到 EJB 2.1 并且已部署到 WebSphere Application Server V6 的消息驱动的 bean,必须对 Java 连接器体系结构(JCA)1.5 资源适配器而不是侦听器端口(如 WebSphere Application Server V5 中所示)部署这些消息驱动的 bean。必须使用部署描述符编辑器来更改 EJB 2.1 消息驱动的 bean 的 WebSphere 绑定设置以使用 JCA 适配器。请参阅配置 EJB 2.1 消息驱动的 bean 以使用 JCA 适配器

    迁移的 EJB 2.0 消息驱动的 Bean 工件是:

    某些 EJB 2.0 消息驱动的 Bean 元素被替换为 activation-config 属性。根据所使用的消息服务的类型,activation-config 属性中用来描述消息传递服务的属性名和值将会有所变化。但是,EJB 2.1 为基于 JMS 的消息驱动的 bean 定义了一组固定属性。

    下列示例将 EJB 2.0 中样本 bean 的元素与 EJB 2.1 中元素的外观进行比较。

    EJB 2.0 中消息驱动的 bean 元素的示例:

    <message-driven id="Mdb20">
    	  <ejb-name>Mdb</ejb-name>
    	  <ejb-class>ejbs.MdbBean</ejb-class>
    	  <transaction-type>Bean</transaction-type>
    	  <message-selector>mdbMessage</message-selector>
    	  <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
    	  <message-driven-destination>
    		<destination-type>javax.jms.Topic</destination-type>
    		<subscription-durability>Durable</subscription-durability>
    	   </message-driven-destination>
    </message-driven>
    

    EJB 2.1 中消息驱动的 bean 元素的示例:

        <message-driven id="Mdb21">
      <ejb-name>Foo/ejb-name>
      <ejb-class>ejbs.FooBean</ejb-class>
       <messaging-type>javax.jms.MessageListener</messaging-type>
       <transaction-type>Bean/transaction-type>
       <message-destination-type>javax.jms.Topic</message-destination-type>
        <activation-config>
    	  <activation-config-property>
    	   <activation-config-property-name>destinationType</activation-config-property-name>
    	   <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	   <activation-config-property-name>subscriptionDurability</activation-config-property-name>
    	     <activation-config-property-value>Durable</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	     <activation-config-property-name>acknowledgeMode</activation-config-property-name>
    	     <activation-config-property-value>AutoAcknowledge</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    		<activation-config-property-name>messageSelector</activation-config-property-name>
    		<activation-config-property-value>fooSelector</activation-config-property-value>
    	  </activation-config-property>
    </activation-config>
    </message-driven>
    

    配置 EJB 2.1 消息驱动的 bean 以使用 JCA 适配器

    对于已从 Enterprise Java Bean(EJB)2.0 迁移到 EJB 2.1 规范级别并且已部署到 WebSphere Application Server V6 的消息驱动的 bean,必须对 Java 连接器体系结构(JCA)1.5 资源适配器而不是侦听器端口部署这些消息驱动的 bean。

    下列步骤描述了如何更改 EJB 2.1 消息驱动的 bean 的部署描述符以使用 JCA 适配器:

    1. 在“项目资源管理器”中打开 EJB 项目。
    2. 在“项目资源管理器”中双击该 EJB 项目的部署描述符文件。EJB 部署描述符编辑器将打开。
    3. 单击 Bean 选项卡以打开 Bean 页面。
    4. 对于 EJB 项目中的每个 EJB 2.1 消息驱动的 bean,执行下列操作:

      1. 在 Bean 页面左边的 bean 列表中选择 EJB 2.1 消息驱动的 bean。
      2. WebSphere 绑定标题下,选择 JCA 适配器按钮。
      3. 指定绑定部署属性:

        1. ActivationSpec JNDI 名称

          输入要用来部署此消息驱动的 bean 的 J2C 激活规范的 JNDI 名称。此名称必须与您对 WebSphere Application Server 定义的 J2C 激活规范的名称相匹配。

        2. ActivationSpec 权限别名

          用于对与 JCA 资源适配器的连接进行认证的 J2C 认证别名的名称。J2C 认证别名指定用来对创建与 JCA 资源适配器的新连接进行认证的用户标识和密码。

        3. 目标 JNDI 名称

          输入消息驱动的 bean 用来在 JNDI 名称空间中查找 JMS 目标的 JNDI 名称。

    5. 保存更改并关闭部署描述符编辑器。

    Web 项目(Servlet 级别 2.3 到 Servlet 级别 2.4)

    将 J2EE 1.3 级别 Web 项目迁移到 J2EE 1.4 级别时,J2EE 迁移向导会迁移 Web 部署描述符的工件。

    将迁移下列 Web 应用程序工件:

    认证约束

    J2EE 1.4 包括具有下列两个属性的描述对象:languagevalue。此描述对象在 J2EE 1.3 中不存在;描述是“认证约束”上的一个属性。所以,将 Web 部署描述符的工件迁移到 J2EE 1.4 时,描述对象的 value 将取自“认证约束”的描述属性。

    安全性约束

    同样,在 J2EE 1.3 中,描述是“安全性约束”上的一个属性。在 J2EE 1.4 中,有一个新的描述对象带有属性 languagevalue。所以,描述对象的 value 将取自“安全性约束”的描述属性。

    Web 应用程序

    J2EE 1.3 规范级别中的 ContextParam 对象的描述字符串属性在 J2EE 1.4 中已移至 ParamValue 中的描述对象。

    J2EE 1.3 中的 TagLib 对象在 J2EE 1.4 中已移至 JSPConfig 对象。JSPConfig 对象在 1.3 中属于 Web 根对象。

    连接器项目(JCA 1.0 到 JCA 1.5)

    J2EE 迁移向导将 J2EE 连接器体系结构(JCA)1.0 描述符的工件迁移到 JCA 1.5。已迁移的工件与 ResourceAdaptor 对象的元素相关,因为已将两个新对象(OutboundResourceAdaptor 和 ConnectionDefinition)添加至 J2EE 1.4 规范级别的连接器项目中的 ResourceAdaptor 对象。

    下面描述了已迁移元素的映射。

    Web Service(J2EE 1.3 到 J2EE 1.4)

    J2EE 1.4 规范通过新的 JAX-RPC 1.0 API 添加了对 Web Service 的支持。

    JAX-RPC API 通过下列内容支持服务端点:

    J2EE 1.4 规范支持 J2EE 规范(JSR 109)的 Web Service。JSR 109 定义 Web Service 的部署需求并使用 JAX-RPC 编程模型。

    使用 J2EE 迁移向导迁移的 Web Service 工件如下:

    迁移 Web Service 部署描述符

    J2EE 1.3 项目中包含的要迁移到 J2EE 1.4 规范级别的任何 Web Service 部署描述符都将从 JSR-109 V1.0(J2EE 1.3)迁移到 J2EE 1.4。

    如 JSR-109 V1.0 所定义的那样,Web Service 部署描述符由文件 webservices.xml、webservicesclient.xml 及 webservices.xml 和 webservicesclient.xml 文件引用的所有 JAX-RPC 映射部署描述符组成。 与其它 J2EE 部署描述符一样,迁移会修改描述符中包含的信息的结构以使它们符合 J2EE 1.4 规范。对 Web Service 部署描述符来说比较特别的一个结构更改是对表示限定名的方式的更改。在 JSR-109 V1.0 中,限定名是使用两个元素(<namespaceURI><localpart>)的序列表示的,这两个元素分别包含名称空间 URI 和名称的本地部分。J2EE 1.4 中的限定名基于使用 XML 名称空间的 XMLSchema QName 类型。

    下面提供了有关迁移每个 Web Service 部署描述符的更多详细信息。


    J2EE 1.2 到 1.4 规范级别迁移

    可将 J2EE 模块从 J2EE 1.2 规范级别迁移到 J2EE 1.4。本节描述通过 J2EE 迁移向导将 J2EE 项目从 J2EE 1.2 迁移到 J2EE 1.4 规范级别的工件。

    有关使用 J2EE 迁移向导的详细信息,参阅第 4 章, 迁移 J2EE 项目

    迁移 Enterprise JavaBeans 项目(EJB 1.1 到 EJB 2.1)

    本节描述将 EJB 项目从 EJB 1.1 迁移到 EJB 2.1 规范级别。

    将 EJB 项目从 EJB 1.1 迁移到 EJB 2.1 涉及到容器管理的持久性(CMP)实体 bean 的迁移。

    J2EE 1.3 与 J2EE 1.4 规范级别之间的实体 bean 没有任何更改。将 CMP 实体 bean 从 EJB 1.1 迁移到 EJB 2.1 规范级别的方法与将 CMP 实体 bean 从 EJB 1.1 迁移到 EJB 2.0 的方法相同。将容器管理的实体 bean 从 EJB 1.1 迁移到 EJB 2.x 规范级别需要下列步骤:

    1. 将 EJB 项目从 EJB 1.1 转换到 EJB 2.x
    2. 将 EJB 代码从 EJB 1.1 迁移到 EJB 2.x
    3. 将所有用户定义的 EJB 1.1 引用迁移到 EJB 2.x 中的本地引用

    将项目从 EJB 1.1 转换到 EJB 2.x

    可使用 J2EE 迁移向导将 EJB 1.1 项目转换为 EJB 2.x 项目。

    或者,如果想要保留初始 EJB 1.1 项目,可创建新的 2.x 项目,然后将现有项目 JAR 文件导入其中(文件 -> 导入 -> EJB JAR)。

    虽然项目是 EJB 2.x 项目,但是,现有的(即已导入的)EJB 1.1 容器管理的持久性(CMP)实体 bean 仍然是 EJB 1.1 bean。即,CMP 实体 bean 未转换到 EJB 2.x。

    J2EE 迁移向导将 EJB 2.x 项目中的企业 bean 从 1.1 迁移到 2.x 中。(如果选择了将 1.1 CMP 实体 bean 迁移到 2.x,则必须迁移 2.x 项目中的所有 bean。但是,可以选择将本地客户机视图添加至这些迁移的 2.x bean。)

    注:
    如果具有任何已映射的关联,则将为关联本身创建 EJB 2.x 关联,但是那些关联的角色映射将变得无效。如果运行验证,则您将看到发生错误。为解决此问题,先打开映射编辑器,然后保存映射。角色映射将被除去。然后,可以再次运行验证并重新映射角色。

    将代码从 EJB 1.1 迁移到 EJB 2.x

    对于从 EJB 1.1 转换为 EJB 2.x 的项目,必须执行一些步骤才能将现有 EJB 1.1 代码迁移到 EJB 2.x。

    注:
    EJB 2.x bean 只在 EJB 2.x 项目中受支持(但是 2.x 项目也支持 1.1 bean)。

    1. 对于任何 CMP 1.1 bean,将每个 CMP 字段替换为抽象 getXXXsetXXX 方法。(然后,需要将 bean 类抽象化。)
    2. 对于任何 CMP,为主键创建抽象 getXXXsetXXX 方法。
    3. 对于任何 CMP 1.1 finder 方法,为每个 finder 方法创建 EJBQL(EJB 查询语言)方法。
      注:
      “EJB 查询语言”在 Rational Application Developer V6.0 中具有下列局限性:
      • 涉及具有某些键(这些键由与其它 EJB 的关系组成)的 EJB 的“EJB 查询语言”查询将显示为无效,并且会在部署时导致错误。
      • IBM EJB 查询语言支持以各种方式扩展 EJB 2.x 规范,包括放松某些限制及添加对更多 DB2 函数的支持等等。如果在各种供应商数据库或 EJB 部署工具之间的可移植性非常重要,则编写所有“EJB 查询语言”查询时应当小心,要严格按照 EJB 2.x 规范的第 11 章中的指示信息进行。
    4. 对于任何 CMP 1.1 finder,返回 java.util.Collection 而不是 java.util.Enumeration
    5. 对于任何 CMP 1.1 bean,在 ejbCreate() 和整个代码的其它任何地方,将所有出现的 this.field = value 更改为 setField(value)
    6. 为非应用程序异常更新异常处理(回滚行为):
    7. 为应用程序异常更新异常处理(回滚行为):
    8. 更新 ejbCreate 中特定于应用程序的缺省值的任何 CMP 设置 (不使用全局变量,因为在调用 ejbCreate 覆盖先前的特定于应用程序的缺省值之前,EJB 1.1 容器将所有字段设置为类属缺省值)。

    迁移 EJB 1.1 关系的 EJB 引用

    当创建 EJB 1.1 关系时,将创建对“远程客户机”视图的 EJB 引用。在使用 J2EE 迁移向导进行 EJB 1.1 项目迁移期间,将除去对 EJB 1.1 关系的这些 EJB 远程引用,并替换为 EJB 本地引用。必须为用户定义的 EJB 引用手工创建本地引用。

    注:
    在 EJB 2.x 中,仅当对 bean 定义了“本地客户机”视图时才能创建 EJB 关系,并且 EJB 本地引用是为 EJB 2.x 关系创建的。

    对于用户定义的 EJB 引用,迁移不是使用 J2EE 迁移向导完成的。而是遵循下列步骤来设置本地引用:

    1. 删除部署描述符编辑器的“引用”页面中的现有 EJB 远程引用。
    2. 在部署描述符编辑器的“引用”页面中添加 EJB 本地引用。

    在迁移项目结构期间合并了方法元素

    在使用 J2EE 迁移向导迁移项目结构期间,所有 bean 的相同类型的方法元素(包括安全标识、容器事务、方法许可权、访问意向和隔离级别)会合并以按逻辑组合。

    项目结构迁移前后的方法元素的样本。

    以下是项目结构迁移之前在部署描述符编辑器的“源代码”页面中的方法许可权的样本。

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-namae>remove</method-name>
    				<method-params>
    					<method-param>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    

    以下是项目结构迁移之后在部署描述符编辑器的“源代码”页面中的方法许可权的样本。

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    
    注:
    当在 J2EE 迁移向导中选择了项目结构迁移还同时选择了从 CMP 1.x 迁移到 CMP 2.x bean 时,在迁移期间会除去访问意向和隔离级别,但是会合并其它任何内容。会除去访问意向和隔离级别的原因是由于扩展模型中的更改使它们不再有效。通过使用新的模型,我们在访问意向中同时定义了访问意向和隔离级别,我们同时具有 Bean 级别访问意向和方法级别访问意向。始终建议使用 Bean 级别访问意向而不使用方法级别访问意向。

    Web 项目(Servlet 级别 2.2 到 Servlet 级别 2.4)

    将 J2EE 1.2 Web 项目迁移到 J2EE 1.4 规范级别时,J2EE 迁移向导会迁移 Web 部署描述符的工件。

    将迁移下列 Web 应用程序工件:

    认证约束

    J2EE 1.4 包括具有下列两个属性的描述对象:languagevalue。此描述对象在 J2EE 1.2 中不存在;描述是“认证约束”上的一个属性。所以,将 Web 部署描述符的工件迁移到 J2EE 1.4 时,描述对象的 value 将取自“认证约束”的描述属性。

    安全性约束

    同样,在 J2EE 1.2 中,描述是“安全性约束”上的一个属性。在 J2EE 1.4 中,有一个新的描述对象带有属性 languagevalue。所以,描述对象的 value 将取自“安全性约束”的描述属性。

    Web 应用程序

    J2EE 1.2 规范级别中的 ContextParam 对象的描述字符串属性在 J2EE 1.4 中已移至 ParamValue 中的描述对象。

    J2EE 1.2 中的 TagLib 对象在 J2EE 1.4 中已移至 JSPConfig 对象。JSPConfig 对象在 1.2 中属于 Web 根对象。


    Rational Application Developer V6.0 中 J2EE 迁移向导中的更改

    已经对 Rational Application Developer V6.0 中的 J2EE 迁移向导进行了更改,这些更改对于所有 J2EE 规范级别的迁移都是公共的。

    项目结构迁移是可选的

    在 WebSphere Studio V5.1.x 到 V5.1.2 中,项目结构迁移与 J2EE 规范级别迁移是同时发生的。在迁移 J2EE 规范级别时,项目结构迁移不是可选的一项。

    在 Rational Application Developer V6.0 的 J2EE 迁移向导中,迁移项目结构是一个独立于迁移项目 J2EE 规范级别的一个可选项。J2EE 规范级别迁移和项目结构迁移可以独立执行。

    目标服务器是必需的

    在 Rational Application Developer V6.0 中,迁移到较高的 J2EE 规范级别的新的和现有的 J2EE 项目需要在项目上设置目标服务器。确定目标服务器是 V6.0 中如何在 J2EE 项目上设置类路径的缺省柄制。有关设置目标服务器和使用 J2EE 迁移向导的更多信息,请参阅联机帮助。


    第 5 章 迁移到 Rational Application Developer V6.0 中的门户网站工具

    Portal Toolkit V5.0.2.2 项目将自动迁移到 Rational Application Developer V6.0 门户网站工具,方法是通过迁移 Portal Toolkit 工作空间、从 SCM(源代码管理)系统装入项目或使用“项目交换”功能部件导入项目。如果要从 Portal Toolkit 的较早版本进行迁移,将需要把 Portlet 项目导出为 WAR 文件,然后将 WAR 文件导入到 Rational Application Developer V6.0 中的门户网站工具中。

    在迁移门户网站应用程序之前,必须安装 Rational Application Developer V6.0 的门户网站工具功能部件。参阅《安装指南》

    注:
    不支持 Portlet 项目的向后兼容性。

    只有在 WebSphere Studio V5.1.2 的 Portal Toolkit V5.0.2.2 创建的项目支持自动迁移。有关迁移详细信息,请参阅第 1 章, 从 WebSphere Studio V5.1、5.1.1 或 5.1.2 进行迁移

    如果 Portlet 项目与企业应用程序项目相关联,则将需要在 EAR 项目上设置适当的目标服务器。可以在服务器属性页(属性 -> 服务器)上设置目标服务器。

    在迁移 Portal Toolkit V5.0.2.2 项目期间,会发生一些其它更改:

    如果要从 Portal Toolkit 的较早版本进行迁移,则需要将 Portlet 项目手工迁移到 Rational Application Developer V6.0 中的门户网站工具中。

    1. 将现有项目导出至 WAR 文件: 在较早版本的 Portal Toolkit 中,将每个项目导出到具有源文件的 WAR 文件中。

      1. 右键单击项目并选择导出
      2. 选择 WAR 文件导出源文件并单击完成
    2. 导入 Portlet WAR 文件:

      1. 在 Rational Application Developer V6.0 的门户网站工具中,创建新的空 Portlet 项目。

        1. 选择文件 -> 新建 -> 项目 -> 门户网站 -> Portlet 项目或 Portlet 项目(JS4 168)
        2. 取消选择创建 Portlet
        3. 单击显示高级
        4. 如果要导入 WebSphere Portal 4.2 Portlet,则选择 2.2 作为 servlet 版本。
        5. 选择 WebSphere Portal V5.0 作为目标服务器,然后单击完成
      2. 将 WAR 文件导入这个新的空 Portlet 项目。

        1. 选择导入
        2. 选择 WAR 文件并指定前面导出的那个 WAR 文件(将项目导出到较早版本的 WAR 文件中)。
        3. 选择新的空 Portlet 项目。
        4. 选择覆盖现有资源而不发出警告
        5. 不要选择覆盖时删除项目
    3. 删除 TLD 文件:

      如果项目中存在 Portlet TLD 文件,建议您删除该文件。否则,重建项目时您会接收到警告消息。保留该文件在将 Portlet 项目部署到 WebSphere Portal 时可能会产生问题,Portlet 的 TLD 文件不同于服务器中的 TLD 文件。

    4. 如果要导入 WebSphere Portal 4.2 Portlet,则需要将这个迁移的 Portlet 项目迁移到 WebSphere Portal 5.x。

    有关将 WebSphere Portal V4.2 Portlet 迁移到 V5.x 的信息,参阅将 WebSphere Portal V4.2 Portlet 迁移到 V5.x

    有关迁移 Portlet 项目中的 Faces 资源的信息,参阅更新 Portlet 项目中的 Faces 运行时资源


    将 WebSphere Portal V4.2 Portlet 迁移到 V5.x

    Rational Application Developer V6.0 不支持开发 WebSphere Portal V4.2 Portlet。需要将 WebSphere Portal V4.2 Portlet 项目迁移到 V5.x。

    为 WebSphere Portal V4.2 编写的大部分 Portlet 无需更改就可以在 WebSphere Portal V5.x 中运行。现在将一些 Portlet 4.2.x API 标记为建议不要使用,但在 WebSphere Portal V5.x 上仍然可用。

    注:
    迁移的 Portlet 应用程序项目不是向后兼容的。

    要将 WebSphere Portal V4.2 的 Portlet 应用程序迁移到 V5.x,执行下列步骤:

    1. 将 Portal V4.2 Portlet 项目迁移到 Portal 5.x Portlet 项目:

      1. 右键单击想要迁移的 Portlet 应用程序项目。
      2. 选择属性 -> Portlet API 以打开 Portlet API 页。
      3. 从 Portlet API 级别下拉列表中选择 WebSphere Portal V5.x
      4. 单击确定将自动进行下列更改:
        • 如果存在 Portlet API 的标记库描述符(TLD)文件,则除去该文件。
        • Web 级别将从 2.2 更改为 2.3。
        • 将除去特定于 Portlet 的类路径条目,因为 WebSphere Portal JRE 容器和 WebSphere Portal 运行时目标容器将动态添加它们。
    2. 如果 Portlet 项目与企业应用程序项目相关联,则建议您将 EAR 项目的 J2EE 级别迁移到 J2EE 1.3。 为 WebSphere Portal V5.x 设计的 Portlet 应用程序应符合 J2EE 级别 1.3 规范。
      注:
      在将 企业应用程序项目迁移到 J2EE 1.3 之前,阅读第 4 章, 迁移 J2EE 项目。有关使用 J2EE 迁移向导的更多信息,请参阅联机帮助。

      1. 如果迁移的 Portlet 项目只与企业应用程序项目相关联,则执行以下操作:

        1. 关闭工作台中的所有编辑器。
        2. 右键单击与迁移的 Portlet 项目相关联的企业应用程序项目。
        3. 选择迁移 -> J2EE 迁移向导然后单击下一步
        4. 选择 J2EE V1.3 并选择 WebSphere Portal 作为目标服务器。
        5. 单击完成
      2. 如果有其它 Portlet 项目与企业应用程序项目相关联,则必须除去迁移的 Portlet 项目并将它添加至另一个企业应用程序项目。

        1. 从企业应用程序项目中除去迁移的 Portlet 项目的模块。

          1. 展开企业应用程序项目并选择部署描述符。
          2. 选择打开方式 -> 部署描述符编辑器
          3. 选择模块选项卡。在编辑器的“模块”页上,选择迁移的 Portlet 项目的 WAR 文件。
          4. 单击除去
          5. 选择文件 -> 保存以保存更改。
        2. 创建新的企业应用程序项目并向它添加 Portlet 项目。

          1. 选择文件 -> 新建 -> 项目
          2. 选择显示所有向导复选框。
          3. 展开 J2EE 并选择企业应用程序项目
          4. 填写项目名称字段,选择 J2EE V1.3 并选择 WebSphere Portal 作为目标服务器,然后单击下一步
          5. EAR 模块项目页上,选择迁移的 Portlet 项目然后单击完成

    Portlet 项目现在已迁移到 WebSphere Portal V5.x。


    更新 Portlet 项目中的 Faces 运行时资源

    已经对 Rational Application Developer V6.0.1 更新了 WebSphere Studio Application Developer V5.1.2 中最初提供的 JavaServer Faces 运行时资源。如果想要继续在使用此先前产品版本的 Portal Toolkit 5.0.2.2 创建的 Portlet 项目上进行开发,建议您将 Faces 运行时资源更新为最新级别。

    在 Rational Application Developer V6.0.1 中,当导入 Portlet 项目或者打开包含过时资源的工作空间时,就会自动更新 Faces 运行时资源。在将使用 WebSphere Studio Application Developer V5.1.x 的 Portal Toolkit 5.0.2.2 创建的 Portlet 项目导入到 Rational Application Developer V6.0.1 之后,将提示您将 Faces 运行时资源更新为最新级别。

    自动更新运行时资源

    自动更新 Portlet 项目的 Faces 运行时资源:

    1. 导入一个包含来自于 WebSphere Studio Application Developer V5.1.x 的 Faces 内容的 Portlet 项目。“项目迁移”窗口打开。
      注:
      如果“项目迁移”窗口未打开,则可能已经禁用了自动构建首选项设置。在“项目资源管理器”中,右键单击 Portlet 项目并选择构建 -> 项目;重建项目的过程将打开“项目迁移”窗口。
    2. 如果工作空间中具有其它包含 Faces 内容的 Portlet 项目,则选择将此选项应用于需要升级的其它任何项目,就会更新所有 Portlet 项目。
    3. 单击下列其中一项:
    4. 要更新特定于 Portlet 的 Faces 运行时资源 jsf-portlet.jar 和 jsf-wp.jar,您需要遵循下面的手工更新步骤。
    注:
    如果您创建了包含 Faces Client 组件的 Faces JSP,则必须单独将 Faces Client 组件运行时资源更新为最新级别。请参阅更新 Web 项目中的 Faces Client 运行时资源

    手工更新运行时资源

    手工更新 Portlet 项目的 Faces 运行时资源:

    1. 将具有 Faces 内容的现有 Portlet 项目导入到 Rational Application Developer V6.0.1 工作空间中。
    2. 使用在第二页中选择的 Faces Portlet 选项创建新的名为 JSFP601 的 Portlet 项目。仅将此项目用作最新运行时资源的源;在完成更新之后可以删除它。
    3. 在“项目资源管理器”中,右键单击 JSFP601 项目并从菜单中选择属性
    4. 单击 Web 项目功能部件并选择为 Portlet 项目添加 Faces Client 框架,然后单击确定
    5. 对于想要更新的每个现有 Faces 项目,执行下列操作:

      1. 在“项目资源管理器”中展开现有项目以显示 WebContent/WEB-INF/lib/ 文件夹中的文件。找到此目录中的下列任何 JAR 文件并删除它们:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. 找到文件 WebContent/WEB-INF/faces-config.xml 并打开它。如果下列元素不存在,则将它们添加到此配置文件中:
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
        注:
        如果 Portlet 项目正在使用 JSR 168 API,则指定 com.ibm.faces.application.PortletVariableResolver 而不是 com.ibm.faces.application.WPPortletVariableResolver
      3. 对于删除的任何 JAR 文件,复制 JSFP601 项目的 WebContent/WEB-INF/lib 目录中的同名 JAR 文件并将其粘贴到原始项目中的同一位置。某些配置并不需要在项目中有所有这些 JAR 文件;如果原始项目没有某个 JAR 文件,则不要复制它。
        • 如果 Portlet 项目使用 IBM Portlet API 或人员链接组件,则将 jsf-wp.jar 文件复制到原始项目中。
        • 如果复制 odc-jsf.jar 文件,则还应复制 odc-jsf-portlet.jar 文件。
      4. 在原始项目中打开 web.xml 部署描述符并将下列内容添加至配置:
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>
        	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
    6. 删除 JSFP601 Portlet 项目。

    第 6 章 WebSphere 测试环境的更改

    在 Rational Application Developer V6.0 中,随该产品一起提供的 WebSphere Application Server 测试环境已从 WebSphere Studio Application Developer 的先前版本一起提供的测试环境进行了更改。

    以下是 Rational Application Developer V6.0 中的 WebSphere Application Server 测试环境中所作的更改总结:

    下表显示 WebSphere Studio Application Developer 和 Rational Application Developer 的不同版本提供的 WebSphere Application Server 测试环境级别。


    表 2. WebSphere Studio Application Developer 和 Rational Application Developer 中的 WebSphere Application Server 测试环境


    WebSphere Application Server V4.x AEs WebSphere Application Server V5.x Base WebSphere Application Server Express 5.x WebSphere Application Server V5.x Portal WebSphere Application Server V6.0
    WebSphere Studio Application Developer V5.1 V4.0.6 V5.0.2 V5.0.2 不适用 不适用
    WebSphere Studio Application Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 不适用 不适用
    WebSphere Studio Application Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 V5.0.2.3 Base + WebSphere Portal V5.0.2.1 不适用
    Rational Application Developer V6.0 不适用 V5.0.x, V5.1.1 V5.0.2 & V5.1.1 V5.0.2.6 Base + WebSphere Portal V5.0.2.2 和 V5.1.1 Base + WebSphere Portal 5.1 V6.0

    版权和声明