IBM Rational Application Developer for Windows 和 Linux 6.0 版移轉手冊


目錄

第 1 章 從 WebSphere Studio 5.1、5.1.1 或 5.1.2 移轉

  • WebSphere Studio 5.1.x 版的相容性
  • 停用與 WebSphere Studio 5.1.x 版的相容性
  • 更新 Web 專案中的 Faces 執行時期資源
  • 更新 Web 專案中的 Faces 用戶端執行時期資源
  • 移轉 Struts Web 專案
  • 6.0 版的除錯器變更
  • WDO 至 SDO 移轉
  • 6.0 版中的 EGL 保留字
  • 第 2 章 從 Rational Application Developer 6.0 版更新 Web 專案的 Faces 執行時期資源

    第 3 章 從 Rational Application Developer 6.0 版更新 Portlet 專案的 Faces 執行時期資源

    第 4 章 移轉 J2EE 專案

  • 移轉安全 Web 服務
  • 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 服務(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 6.0 版中 J2EE 移轉精靈的變更
  • 第 5 章 移轉至 Rational Application Developer 6.0 版中的入口網站工具

  • 將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版
  • 更新 Portlet 專案中的 Faces 執行時期資源
  • 第 6 章 WebSphere 測試環境的變更



    第 1 章 從 WebSphere Studio 5.1、5.1.1 或 5.1.2 移轉

    這份文件提供從 WebSphere(R) Studio Application Developer 5.1.x 版移轉至 Rational(R) Application Developer 6.0 版的指示。

    其他資訊可於下列主題取得:

    如果需要使用 Rational Application Developer 的相關資訊,請參閱線上說明。

    請參閱 www.ibm.com/developerworks/rational,以取得更新的文件。

    如果需要從舊版 WebSphere Studio 移轉至 5.x 版,或從 VisualAge(R) for Java(TM) 移轉至 WebSphere Studio 的相關資訊,請移至 www.ibm.com/software/awdtools/studioappdev/support/,搜尋「移轉手冊」

    如果要從 WebSphere Studio 5.1.x 版移轉,請執行下列動作:

    1. 安裝之前,請先閱讀與 Eclipse 2.x 版和 WebSphere Studio 5.1.x 版的相容性的相關資料。 請注意,從 Portal Toolkit 5.0.2.2 版移轉的 Portlet 應用程式專案沒有與 WebSphere Studio 5.1.2 版的舊版相容性支援。
    2. 備份您的 WebSphere Studio 5.1.x 版工作區。
    3. 安裝 Rational Application Developer。請參閱安裝手冊(install.html 檔),它在第一片產品 CD 的根目錄中。
    4. 建議:依預設,第一次啟動 Rational Application Developer 時,會提示您確認您要使用稱為 rationalsdp6.0\workspace 的工作區。也就是說,「工作區啟動程式」對話框會指向不是您的 WebSphere Studio 工作區的目錄。如果要在移轉舊工作區之前探索新環境,在啟動 Rational Application Developer 時,請接受預設值,或指定某個其他新目錄名稱。您可能會這麼做,比方說,以便能夠建立一、兩個測試專案,閱讀新增功能的相關資訊(說明 -> 歡迎使用),執行某些新的指導教學(說明 -> 指導教學展示區),或體驗某些新範例(說明 -> 範例展示區)。
    5. 將專案移轉至 6.0 版。您可以依照下列方式,將 WebSphere Studio 5.1.x 版中所建立的專案自動移轉至 6.0 版:
      1. 移轉工作區:當您準備好永久移轉 5.1.x 版工作區時,請利用舊工作區來啟動 Rational Application Developer。這時會出現一個進度指示器,確認正在自動移轉您的專案。

        附註:在工作區移轉期間,會開啟問題對話框,其中含有下列訊息:無法還原工作台佈置。原因:還原工作台時,發生問題。這個錯誤訊息不會影響工作區的順利移轉。 請按一下錯誤對話框中的詳細資料按鈕來記下無法還原的視景名稱,再按一下確定來關閉對話框。

        如果要還原視景,請執行下列動作:

        1. 選取視窗 -> 關閉視景來關閉視景
        2. 選取視窗 -> 開啟視景來重新開啟視景。
        註:
        對於在 WebSphere Studio 5.1.2 版中使用 EGL Web 視景的 Enterprise Generation Language (EGL) 專案:Rational Application Developer 6.0 版已移除了這個視景。所有 EGL 專案已在沒有這個視景的情況下,在 Rational Application Developer 6.0 版中安全移轉。如果您使用 EGL Web 視景,請執行下列動作:
        1. 關閉 EGL Web 視景。
        2. 在「喜好設定」中啟用 EGL 功能(視窗 -> 喜好設定)。請參閱線上說明,以取得啟用 EGL 功能的詳細資料。
        3. 選取視窗 -> 開啟視景,再選擇 Web 視景。
      2. 移轉從 SCM(原始碼管理)系統中載入的專案:當 SCM 系統中的 WebSphere Studio 5.1.x 專案載入 Rational Application Developer 時,會自動移轉至 6.0 版。
      3. 移轉利用專案交換匯入的專案:從 WebSphere Studio 5.1.2 或 5.1.1 匯出,再利用專案交換特性匯入 Rational Application Developer 6.0 版的專案會自動移轉至 6.0 版。 WebSphere Studio 5.1.2 版提供了專案交換特性,在 5.1.1 版中,它是一個選用的外掛程式。

      附註:

      重要事項:

    6. Rational Application Developer 6.0 版不支援 DB2(R) Net JDBC Driver。如果您利用 DB2 Net JDBC Driver 建立了 JDBC 連線,您將無法在 Rational Application Developer 6.0 版中重新連線。您必須變更連線來使用其中一種支援的 JDBC 驅動程式。請參閱線上說明,以取得 6.0 版的 JDBC 驅動程式的詳細資訊。
    7. 如果您有從 WebSphere Studio Application Developer 5.1.x 版移轉的 Web 或 XML 檔使用 Shift_JIS 字集且包括供應商選取的字元,您必須另行指定 Windows-31J 字集。
    8. 如果您在 WebSphere Studio Application Developer 5.1.x 版中安裝了任何供應商外掛程式,您必須取得 6.0 版的對應外掛程式,再重新安裝它們。
    9. 如果您在安裝 Rational Application Developer 時,安裝了任何前一版的 WebSphere 5.x 版單元測試環境,且您使用內嵌傳訊服務,請安裝 Rational Application Developer 所提供的版本來升級它。請參閱安裝手冊,以取得安裝內嵌傳訊服務的詳細資料。
    10. 如果您使用需要 Agent Controller 的特性,請安裝 Rational Application Developer 所提供的版本來升級它。 如果需要詳細資料,請參閱安裝手冊
    11. 如果要從 VisualAge Generator 移轉,請參閱 VisualAge Generator to Enterprise Generation Language (EGL) Migration Guide 一書, 您可以在 "Accessing the VisualAge Generator to EGL Migration Guide" 說明主題之下,在線上說明的 "Installing and migrating" 一節中找到它的 PDF 檔。您可以從 http://www.ibm.com/developerworks/rational/library/egldoc.html 取得最新的版本。

    WebSphere Studio 5.1.x 版的相容性

    當您第一次在 Rational Application Developer 中開啟任何 WebSphere Studio 5.1.x 版工作區時,都會自動移轉它。移轉工作區之後,您就不能在 WebSphere Studio Application Developer 中開啟它。不過,您仍可以利用專案交換匯入和匯出專案來使用原始碼管理 (SCM) 系統(如 Rational ClearCase(R)), 或匯入保存檔和匯出專案,而與 WebSphere Studio 5.1.x 版共用 6.0 版工作區中的專案。重要事項:已移轉至 Rational Application Developer 6.0 版之入口網站工具的 Portal Toolkit 5.0.2.2 版中的 Portlet 應用程式與舊版不相容。

    註:
    以下內容不適合 Portlet 應用程式專案。

    如果您沒有執行下列中的任何動作,利用專案交換,從 SCM 系統或另一位開發人員載入 6.0 版的現有 5.1.x 版專案都是相容的,能夠與 5.1.x 版共用:

    當在 Rational Application Developer 6.0 版工作區中開啟 5.1.x 版專案時,會自動在專案目錄中建立 .compatibility 檔。當移轉這些資源時,Rational Application Developer 會利用 .compatibility 檔來追蹤專案資源的時間戳記。 您不應該編輯或刪除它。

    如果需要停用與 WebSphere Studio Application Developer 5.1.x 版之相容性的相關資訊,請參閱停用與 WebSphere Studio 5.1.x 版的相容性

    Eclipse 考量

    Rational Application Developer 的這個版本以 Eclipse 3.0 版為基礎。 如果您要開發您自己的外掛程式,您應該在移轉之前閱讀平台變更的相關資訊。

    如果需要詳細資料,請參閱 Rational Application Developer 6.0 版安裝位置之 eclipse\readme 子目錄中的 Readme 檔。Readme 檔中有關移轉的章節如下:

    J2EE 專案相容性

    WebSphere Studio 5.1.x 版所建立之專案與 Rational Application Developer 6.0 版的相容性是利用移轉 5.1.x 版工作區時自動新增至 .project 檔中的 Meta 資料來啟用的。同樣地,如果您在 Rational Application Developer 6.0 版中建立新的 J2EE 1.2 或 1.3 模組或應用程式,建置 Meta 資料會自動新增至 .project 檔中,以便與 5.1.x 版相容。 請勿直接編輯或刪除這項資訊。

    註:
    當在 WebSphere Studio Application Developer 5.1.x 版中使用 6.0 版所建立的新 J2EE 1.2 和 J2EE 1.3 模組或應用程式,且沒有 6.0 版建置器時,這個相容性 Meta 資料會造成顯示或記載「遺漏建置器」的訊息。 這些訊息是正常的;您可以忽略它們。

    只要這個相容性 Meta 資料存在,當在 WebSphere Studio 5.1.x 版中重新載入 Rational Application Developer 6.0 版專案時,都會出現「遺漏建置器」的訊息。 以下是「遺漏建置器」訊息的範例:

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE 跳過 Test60EARWeb 專案的 com.ibm.wtp.j2ee.LibCopyBuilder 建置器。
    可能是安裝時遺漏建置器,或是建置器所屬的專案本質遺漏或停用。
    

    這些訊息是正常的;您可以忽略它們。當您確定已不需要在 WebSphere Studio 5.1.x 版中使用給定的專案時,您可以停用這個專案的舊版相容性來停止這則訊息。

    重要事項:在 6.0 版中建立的新 J2EE 1.2 或 1.3 規格專案相容於 WebSphere Studio 5.1.x 版,但專案載入 WebSphere Studio 之後,您必須先手動執行一些步驟,之後,才能使用這個專案。這些步驟是必要的,因為在 6.0 中建立的新 J2EE 1.2 或 1.3 規格專案上的執行時期目標,不直接相容於舊的 5.1.x 版目標伺服器。以下是在 5.1.x 版中載入新的 6.0 版專案之後的手動步驟:

    1. 開啟每個有 .classpath 檔的 J2EE 專案的 .classpath 檔。
    2. 從 .classpath 檔中刪除下列類別路徑項目,再儲存和關閉檔案。
    3. 確定已在 J2EE 喜好設定頁面中啟用鎖定目標伺服器支援。 選取視窗 -> 喜好設定 -> J2EE,確認已在「鎖定目標伺服器支援」之下,選取啟用鎖定目標伺服器支援
    4. 用滑鼠右鍵按一下專案,選取內容 -> J2EE
    5. 選取專案執行時期目標的對應目標伺服器(如使用 JDK 1.4 執行時期環境的 WebSphere Application Server 5.1 版),再按一下確定
    6. 您選取的目標伺服器將相容於 Rational Application Developer 6.0 版和 WebSphere Studio Application Developer 5.1.x 版。在 SCM 系統中確定變更之後,J2EE 專案就無法利用 SCM 系統在 5.1.x 版和 6.0 版之間交互作業。
      註:
      如果在 Rational Application Developer 6.0 版之中重新設定目標伺服器,將會失去 J2EE 專案相容性,必須重新建立。

    UML 圖解相容性

    在 WebSphere Studio Application Developer 5.1.x 版中的 UML 圖解相容於新版,能夠在 Rational Application Developer 6.0 版中開啟唯讀模式。在 6.0 版中,J2EE 移轉精靈會在 J2EE 專案結構移轉期間,自動移轉 5.1.x 版 J2EE 專案中所建立的 UML 圖解。移轉之後,就可以在 Rational Application Developer 6.0 版中編輯 UML 圖解。

    註:
    移轉至 Rational Application Developer 6.0 版或在其中建立之工作區中的 UML 圖解,無法在 WebSphere Studio Application Developer 5.1.x 版中開啟。

    停用與 WebSphere Studio 5.1.x 版的相容性

    您可以從 Rational Application Developer 6.0 版所建立的企業應用程式專案中,或從移轉自舊版 WebSphere Studio 的企業應用程式專案中,完全移除與 WebSphere Studio Application Developer 5.1.x 版的相容性。只有在確定企業應用程式專案應不再具有與 5.1.x 版交互作業或相容的功能時,您才應停用與 WebSphere Studio 5.1.x 版的相容性。

    如果要移除與 WebSphere Studio Application Developer 5.1.x 版的相容性,請執行下列動作:

    1. 用滑鼠右鍵按一下企業應用程式專案,從蹦現視窗中選取移除相容性功能表選項。
    2. 這時會開啟一個對話框,要求您確認要移除企業應用程式專案以及這個專案之下的所有巢狀模組和公用程式專案的舊版相容性。
    3. 按一下繼續執行「移除相容性」作業。

    執行「移除相容性」作業之後,企業應用程式專案以及企業應用程式專案下的所有巢狀模組和公用程式專案都不再相容於 WebSphere Studio Application Developer 5.1.x 版。


    更新 Web 專案中的 Faces 執行時期資源

    原來在 WebSphere Studio Application Developer 5.1.x 版中所附的 JavaServer Faces 執行時期資源, 在 Rational Application Developer 6.0.1 版已更新。如果您要繼續在以這個舊產品版本建立的 Web 專案上進行開發,建議您將 Faces 執行時期資源更新到最新的層次。

    在 Rational Application Developer 6.0.1 版中,當匯入的 Web 專案或開啟的工作區含有過期的資源時,Faces 執行時期資源即會自動更新。 在從 WebSphere Studio Application Developer 5.1.x 版匯入 Web 專案或開啟工作區至 Rational Application Developer 6.0.1 版之後,系統會提示您將 Faces 執行時期資源更新到最新的層次。

    自動更新執行時期資源

    若要自動更新 Web 專案的 Faces 執行時期資源,請執行下列動作:

    1. 從 WebSphere Studio Application Developer 5.1.x 版匯入含有 Faces 內容的 Web 專案(或工作區)。這時會開啟「專案移轉」視窗。
      註:
      如果「專案移轉」視窗未開啟,您的自動建置喜好設定可能已停用。請在專案瀏覽器中, 用滑鼠右鍵按一下 Web 專案,然後選取建置 -> 專案;重新建置專案的程序即會開啟「專案移轉」視窗。
    2. 如果工作區中有其他 Web 專案含有 Faces 內容,請勾選將這個選項套用到任何其他需要升級的專案,則所有的 Web 專案都會更新。
    3. 按下列其中一項:
    註:
    如果您建立了含有「Faces 用戶端」元件的 Faces JSP, 您必須將「Faces 用戶端」元件執行時期資源個別更新到最新的層次。請參閱更新 Web 專案中的 Faces 用戶端執行時期資源

    手動更新執行時期資源

    若要手動更新 Web 專案的 Faces 執行時期資源,請執行下列動作:

    1. 將含有 Faces 內容的現有 Web 專案匯入 Rational Application Developer 6.0.1 版工作區。
    2. 建立名稱為 JSF601 的新 Web 專案(或者如果您使用的是 EGL,則建立新的 EGL Web 專案)。這個專案只會用來作為最新執行時期資源的來源; 其在更新完成之後即可刪除。
    3. 在專案瀏覽器中,用滑鼠右鍵按一下 JSF601 專案,然後從功能表中選取內容
    4. 按一下 Web 專案特性,然後選取新增 Faces 基本元件新增 Faces 用戶端組織架構,然後按一下確定
    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 用戶端執行時期資源

    原來在 WebSphere Studio Application Developer 5.1.x 版中所附的 JavaServer Faces 用戶端執行時期資源, 在 Rational Application Developer 6.0.1 版已更新。如果您要繼續在以這個舊產品版本建立的 Web 專案上進行開發,建議您將 Faces 用戶端執行時期資源更新到最新的層次。

    在 Rational Application Developer 6.0.1 版中,當匯入的 Web 專案或開啟的工作區含有過期的資源時,Faces 用戶端執行時期資源即會自動更新。 在從 WebSphere Studio Application Developer 5.1.x 版匯入 Web 專案或開啟工作區至 Rational Application Developer 6.0.1 版之後,系統會提示您將 Faces 用戶端執行時期資源更新到最新的層次。

    自動更新執行時期資源

    若要自動更新 Web 專案的 Faces 用戶端執行時期資源,請執行下列動作:

    1. 從 WebSphere Studio Application Developer 5.1.x 版匯入含有 Faces 用戶端內容的 Web 專案(或工作區)。這時會開啟「專案移轉」視窗。
      註:
      如果「專案移轉」視窗未開啟,您的自動建置喜好設定可能已停用。請在專案瀏覽器中, 用滑鼠右鍵按一下 Web 專案,然後選取建置 -> 專案;重新建置專案的程序即會開啟「專案移轉」視窗。
    2. 如果工作區中有其他 Web 專案含有 Faces 用戶端內容,請勾選將這個選項套用到任何其他需要升級的專案,則所有的 Web 專案都會更新。
    3. 按下列其中一項:
    4. 從 Web 專案的 Java 資源 -> JavaSource 資料夾中,刪除命名慣例為 com.ibm.dynwdo4jsmediators.<client-data-name> 的所有用戶端資料調節器類別套件。 請刪除名稱為 com.ibm.dynwdo4jsmediators 的套件。這個套件含有專案中用來重新產生調節器之用戶端資料的 Meta 資料(ecore 和 emap 檔)。
    5. 從 Web 專案的 Java 資源 -> JavaSource 資料夾中,開啟 OdysseyBrowserFramework.properties 檔,然後刪除 EMAP_FILESECORE_FILES 的項目。
    6. 對「用戶端資料」視圖中的每一個資料物件,執行下列動作:
      1. 按一下滑鼠右鍵來選取配置
      2. 進階標籤中,按一下從伺服器端資料重新產生來重新產生資料物件的所有調節器。

    手動更新執行時期資源

    若要手動更新 Web 專案的 Faces 用戶端執行時期資源,請執行下列動作:

    1. 完成更新 Web 專案中的 Faces 執行時期資源中的手動更新執行時期資源步驟。
    2. 完成上述自動更新執行時期資源一節的步驟 4-6。

    將含有 Faces 用戶端元件之專案的目標伺服器從 WebSphere Application Server 5.1 版改成 6.0 版時,可能會發生問題。

    將含有 Faces 用戶端元件之專案的目標伺服器從 WebSphere Application Server 5.1 版改成 6.0 版時,可能會發生兩個問題:

    升級至自動化的 Diff 處理常式和處理器

    Diff 處理器和處理常式現在會自動產生。如果您在 WebSphere Studio 5.1.x 版中撰寫 Faces 用戶端元件的 Diff 處理常式和處理器, 建議您捨棄該程式碼,改用自動產生的處理器和處理常式:

    1. 針對 Web 專案中的每一個用戶端資料物件,產生新的 Diff 處理常式和處理器。
      1. 選取用戶端資料物件,按一下滑鼠右鍵來選取配置
      2. 進階標籤中,按一下全部重新產生
    2. 移除您撰寫來呼叫 Diff 處理器和處理常式的程式碼,原因是系統會自動呼叫產生的處理器和處理常式。使用這種程式碼的典型例子是「指令按鈕」元件的指令事件,如:
      String Diff = getClientData1().getDiffStr();
      if (DiffProcessor.Synch(getRoot(), Diff) == true)
       return "";
      return "failure";
      
    3. 從 Web 專案中移除您建立的舊自訂處理常式和處理器所對應的檔案。

    保留對 5.1.x 版所撰寫的自訂 Diff 處理常式和處理器

    雖然不建議您這麼做,但如果您決定需要保留 5.1.x 版的 Diff 處理常式和處理器, 您必須加以修改才能在 6.0 版中運作,因為 DiffHandler 介面和 DiffInfo 類別已變更。

    6.0 版之 Faces 用戶端元件的變更


    移轉 Struts Web 專案

    針對 WebSphere Studio 5.1.x 版中建立的 Struts Web 專案,您必須稍微修改 Web 專案的部署描述子,才能在 WebSphere Application Server 6.0 版執行 EAR 專案。您可能也想要將現有的 Struts 1.0.2 或 Struts 1.1 測試版(2 或 3)Web 專案,手動轉換至 Struts 1.1。

    修改現有 Struts Web 專案的部署描述子

    當 Struts 專案是在 WebSphere Studio 5.x 版中建立時,Web 專案之部署描述子中的 config 參數 (<param-name>config</param-name>) 會設為 WEB-INF/struts-config.xml。WebSphere Application Server 6.0 版這個參數的開頭需要有 "/"。如果您在 WebSphere Application Server 6.0 版執行於 WebSphere Studio 5.1.x 版建立的 Struts Web 專案,您可能會在啟動 EAR 專案時收到 java.net.MalformedURLException 異常狀況。

    註:
    Rational Application Developer 6.0 版會在建立新的 Struts 專案時加入 "/";不過,在從 WebSphere Studio 5.1x 版移轉時,必須手動加入。

    請遵循下列步驟在 6.0 版中,更正 WebSphere Studio 5.1.x 版建立之 Struts Web 專案的部署描述子:

    1. 在「專案瀏覽器」中開啟 Struts Web 專案。
    2. 在「專案瀏覽器」中,按兩下 Web 專案的 Web 部署描述子檔。 這時會開啟 Web 部署描述子編輯器。
    3. 按一下程式碼標籤來開啟「程式碼」頁面。
    4. 變更下面這一行

      <param-value>WEB-INF/struts-config.xml</param-value>(這位於 <servlet></servlet> 標示內)

      to

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

    5. 儲存 Web 部署描述子

    當 EAR 專案重新啟動時,不應發生 java.net.MalformedURLException 異常狀況。

    將 Struts 1.1 測試版 Web 專案轉換至 Struts 1.1

    在 WebSphere Studio 5.1.x 版中,Struts 執行時期程式庫會從 5.0.x 版中的 Struts 1.1 測試版(2 或 3)逐步升級到 Struts 1.1(最終版)。 如果您有現有的 Struts 1.1 測試版(2 或 3)Web 專案,且要轉換至 Struts 1.1(最終版),您可能要手動轉換。 (附註:您不需要將 Struts 1.1 測試版(2 或 3)專案轉換至 Struts 1.1。)

    若要將 Struts 1.1 測試版(2 或 3)專案轉換至 Struts 1.1,請執行下列動作:

    1. 將 Struts 1.1 測試版專案載入 Rational Application Developer 6.0 版工作區中。
    2. 建立新的 Struts 1.1 Web 專案,比方說,名稱為 Struts11。 您需要建立這個暫時專案,以便存取在轉換實際的專案時,所需的 Struts 1.1 執行時期檔案。完成之後,您可以刪除這個專案。
    3. 針對要轉換至 Struts 1.1 的 Struts 1.1 測試版專案,執行下列動作:
      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 5.1.x 版(和 5.0.x 版)中,當您新增 Struts 支援到 Web 專案時,您可以選擇 Struts 1.0.2。 如果您有現有的 Struts 1.0.2 Web 專案,且要轉換至 Struts 1.1,您可能要手動轉換。 (附註:您不需要將 Struts 1.1 測試版(2 或 3)專案轉換至 Struts 1.1。)

    若要將 Struts 1.0.2 專案轉換至 Struts 1.1,請執行下列動作:

    1. 將 Struts 1.0.2 專案載入 Rational Application Developer 6.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。

    6.0 版的除錯器變更

    Rational Application Developer 6.0 版的除錯工具有些改變。 您必須知道這些改變,您的專案才能在移轉之後使用這些工具。您可能需要變更或還原設定。

    移轉工作區和啟動配置

    當在 Rational Application Developer 6.0 版開啟 WebSphere Studio Application Developer 的 5.1.x 版工作區時,不會自動移轉關聯於工作區的下列除錯器啟動配置:

    「除錯」視圖

    「儲存體」和「儲存體對映」視圖已不存在。「記憶體」和「記憶體呈現」視圖已取代了它們。

    XSLT 除錯器

    在 6.0 版中,XSLT 除錯器已有了改變,它的許多視圖和動作都有了大幅的變更。如果需要進一步的資訊,請參閱資訊中心的 XSLT 除錯器文件。

    XSLT 除錯器最重要的變更之一,是相依於隨著 Rational Application Developer 6.0 版而安裝的 JRE。如果您移轉 WebSphere Studio Application Developer 5.1.x 版中的工作區,您必須先修改已安裝的 JRE 來指向正確的位置,之後,才能啟動它的 XSLT 除錯階段作業。如果要執行這個動作,您可以先執行下列動作之一:


    WDO 至 SDO 移轉

    如果您在 Web 專案中建立程式碼,且這個 Web 專案的目標是使用 WebSphere 資料物件 (WDO) 關聯式記錄或關聯式記錄清單的 WebSphere Application Server 5.1 版,當您將這些應用程式的目標鎖定 WebSphere Application Server 6.0 版時,現在,您會使用服務資料物件 (SDO) 關聯式記錄和關聯式記錄清單。當您將應用程式的目標伺服器從 WebSphere Application Server 5.1 版改成 WebSphere Application Server 6.0 版時,WDO 至 SDO 的移轉作業會自動進行。

    變更目標伺服器的方式有兩種:

    請參閱 Rational Application Developer 的線上說明,以取得變更目標伺服器和使用 J2EE 移轉精靈的說明主題。

    相容性考量

    從 WDO 移轉至 SDO 之後,可能會發生類型衝突錯誤

    在利用 WDO 的專案移轉至 SDO 型的專案之後,如果您將 SDO 資料新增至含現有 WDO 資料的現有 JSP 頁面,就可能發生類型衝突的錯誤。 發生這個情況是因為混合了現有的 WDO Access Bean 和獨立式 SDO API。比方說,您可能會見到類似下列中的 JSP 之 Java 程式檔編譯錯誤:

    import com.ibm.websphere.sdo.mediator.exception.MediatorException
    與另一個匯入的類型衝突
    

    您可以依照下列方式來更正這些類型衝突錯誤:

    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 ) {
      

    將目標伺服器從 5.1 版改成 6.0 版(WDO 至 SDO)之後的 Web 專案變更

    當目標伺服器從 5.1 版改成 6.0 版時,會自動進行下列變更:

    將伺服器目標從 6.0 版改成 5.1 版(SDO 至 WDO)之後的 Web 專案變更

    當目標伺服器從 6.0 版改成 5.1 版時,會自動進行下列變更:

    將應用程式的 J2EE 層次從 1.3 改成 1.4 之後的 Web 專案變更

    除了將伺服器目標改成 WebSphere Application Server 6.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 taglib 參照中的變更。


    表 1. J2EE 1.3 和 J2EE 1.4 中的 JSP taglib 參照。

    J2EE 1.3 taglib (WDO) J2EE 1.4 taglib (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

    6.0 版中的 EGL 保留字

    這些是 Enterprise Generation Language (EGL) 在 Rational Application Developer 中的新保留字。

    下列為新的保留字:

    在利用這些單字作為變數或組件名稱的 6.0 版工作區中匯入和建置的 WebSphere Studio 5.1.x 版 EGL 程式,都會標示下列訊息:IWN.SYN.2002.e 39/2 輸入 "variableName" 語法錯誤。您可以重新命名變數來更正這個問題。


    第 2 章 從 Rational Application Developer 6.0 版更新 Web 專案的 Faces 執行時期資源

    原來在 Rational Application Developer 6.0 版中所附的 JavaServer Faces 和 Faces 用戶端執行時期資源, 在 Rational Application Developer 6.0.1 版已更新。如果您要繼續在以這個舊產品版本建立的 Web 專案上進行開發,建議您將 Faces 和 Faces 用戶端執行時期資源更新到最新的層次。

    在 Rational Application Developer 6.0.1 版中,當匯入的 Web 專案或開啟的工作區含有過期的 Faces 或 Faces 用戶端執行時期資源時,Faces 和 Faces 用戶端執行時期資源即會自動更新。 在從 Rational Application Developer 6.0 版匯入 Web 專案或開啟工作區至 Rational Application Developer 6.0.1 版之後,系統會提示您將這些執行時期資源更新到最新的層次。

    自動更新執行時期資源

    若要自動更新 Web 專案的 Faces 和 Faces 用戶端執行時期資源,請執行下列動作:

    1. 從 Rational Application Developer 6.0 版匯入含有 Faces 或 Faces 用戶端內容的 Web 專案(或工作區)。 這時會開啟「專案移轉」視窗。
      註:
      如果「專案移轉」視窗未開啟,您的自動建置喜好設定可能已停用。請在專案瀏覽器中, 用滑鼠右鍵按一下 Web 專案,然後選取建置 -> 專案;重新建置專案的程序即會開啟「專案移轉」視窗。
    2. 如果工作區中有其他 Web 專案含有 Faces 或 Faces 用戶端內容,請勾選將這個選項套用到任何其他需要升級的專案,則所有的 Web 專案都會更新。
    3. 按下列其中一項:

    手動更新執行時期資源

    若要手動更新 Web 專案的 Faces 和 Faces 用戶端執行時期資源,請執行下列動作:

    1. 建立名稱為 JSF601 的新 Web 專案(或者如果您使用的是 EGL,則建立新的 EGL Web 專案)。這個專案只會用來作為最新執行時期資源的來源; 其在更新完成之後即可刪除。
    2. 在專案瀏覽器中,用滑鼠右鍵按一下 JSF601 專案,然後從功能表中選取內容
    3. 按一下 Web 專案特性,然後選取新增 Faces 基本元件新增 Faces 用戶端組織架構,然後按一下確定
    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 6.0 版更新 Portlet 專案的 Faces 執行時期資源

    原來在 Rational Application Developer 6.0 版中所附的 JavaServer Faces 和 Faces 用戶端執行時期資源, 在 Rational Application Developer 6.0.1 版已更新。 如果您要繼續在以這個舊產品版本建立的 Portlet 專案上進行開發,建議您將 Faces 和 Faces 用戶端執行時期資源更新到最新的層次。

    在 Rational Application Developer 6.0.1 版中,當匯入的 Portlet 專案或開啟的工作區含有過期的 Faces 或 Faces 用戶端執行時期資源時,Faces 和 Faces 用戶端執行時期資源即會自動更新。 在從 Rational Application Developer 6.0 版匯入 Portlet 專案或開啟工作區至 Rational Application Developer 6.0.1 版版之後,系統會提示您將這些執行時期資源更新到最新的層次。

    自動更新執行時期資源

    若要自動更新 Portlet 專案的 Faces 和 Faces 用戶端執行時期資源,請執行下列動作:

    1. 從 Rational Application Developer 6.0 版匯入含有 Faces 或 Faces 用戶端內容的 Portlet 專案(或工作區)。 這時會開啟「專案移轉」視窗。
      註:
      如果「專案移轉」視窗未開啟,您的自動建置喜好設定可能已停用。請在專案瀏覽器中, 用滑鼠右鍵按一下 Portlet 專案,然後選取建置 -> 專案;重新建置專案的程序即會開啟「專案移轉」視窗。
    2. 如果工作區中有其他 Portlet 專案含有 Faces 或 Faces 用戶端內容,請勾選將這個選項套用到任何其他需要升級的專案,則所有的 Portlet 專案都會更新。
    3. 按下列其中一項:
    4. 若要更新 Portlet 特定的 Faces 執行時期資源、jsf-portlet.jar 和 jsf-wp.jar,您需要遵循以下的手動更新步驟。

    手動更新執行時期資源

    若要手動更新 Portlet 專案的 Faces 和 Faces 用戶端執行時期資源,請執行下列動作:

    1. 建立一個新的 Portlet 專案,名稱為 JSFP601。這個專案只會用來作為最新執行時期資源的來源; 其在更新完成之後即可刪除。
    2. 在專案瀏覽器中,用滑鼠右鍵按一下 JSFP601 專案,然後從功能表中選取內容
    3. 按一下 Web 專案特性,然後選取新增 Portlet 專案的 Faces 用戶端組織架構,然後按一下確定
    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 6.0 版的 J2EE 移轉精靈已更新,以便將 J2EE 專案移轉至 J2EE 1.4 規格層次。J2EE 移轉精靈支援將所有的 J2EE 模組類型,從 J2EE 1.2 和 1.3 這兩個規格移轉至 J2EE 1.4 規格層次。

    請參閱 J2EE 1.3 至 1.4 規格層次移轉J2EE 1.2 至 1.4 規格層次移轉,以取得將 J2EE 1.3 和 1.2 規格層次成品移轉至 J2EE 1.4 規格層次的詳細資料。

    註:
    在使用 J2EE 移轉精靈之前,強烈建議您執行下列步驟:

    您可以依照下列方式來存取 J2EE 移轉精靈:

    1. 在 J2EE 視景的 J2EE 階層視圖中,用滑鼠右鍵按一下您要移轉的企業應用程式專案。
    2. 從蹦現功能表中,選取移轉 -> J2EE 移轉精靈
    3. 在繼續移轉程序之前,遵循 J2EE 移轉精靈「歡迎使用」頁面中的指示。

    附註:

    請參閱線上說明,以取得使用 J2EE 移轉精靈的完整詳細資料。Rational Application Developer 6.0 版中 J2EE 移轉精靈的變更有精靈的變更說明。

    請參閱 J2EE 1.3 至 1.4 規格層次移轉J2EE 1.2 至 1.4 規格層次移轉,以取得 J2EE 1.3 和 1.2 規格層次成品移轉至 J2EE 1.4 時所進行之變更的詳細資料。


    移轉安全 Web 服務

    當 Web 服務從 J2EE 1.3 移轉至 J2EE 1.4 時,J2EE 移轉精靈不會移轉安全 Web 服務。安全 Web 服務的移轉作業需要手動步驟。

    在 J2EE 移轉之後,您必須依照下列方式,將安全連結和延伸規格檔手動移轉至 J2EE 1.4:

    1. 按兩下 webservices.xml 檔來開啟 Web 服務編輯器。
    2. 選取連結配置標籤來編輯連結檔。
    3. 在新的區段要求消費者連結配置詳細資料回應產生者連結配置詳細資料之下,新增所有必要的連結配置。
    4. 選取延伸規格標籤來編輯延伸規格檔。
    5. 在新的區段要求消費者服務配置詳細資料回應產生者服務配置詳細資料之下,新增所有必要的延伸規格配置。
    6. 儲存和結束編輯器。

    J2EE 1.3 至 1.4 規格層次移轉

    J2EE 專案可以從 J2EE 1.3 移轉至 J2EE 1.4 規格層次。這一節說明 J2EE 移轉精靈從 J2EE 1.3 移轉至 J2EE 1.4 的各類型 J2EE 專案的成品。

    Enterprise JavaBean 專案(EJB 2.0 至 EJB 2.1)

    J2EE 移轉精靈支援將 Enterprise Bean 部署描述子從 J2EE 1.3 規格層次的 EJB 資源移轉至 J2EE 1.4。Stateless Session Bean 和訊息驅動 Bean 都會移轉至 J2EE 1.4。

    移轉 Session Bean

    J2EE 移轉精靈會在 Stateless Session Bean 設定服務端點介面,以將在 J2EE 1.3 EJB 專案的 webservices.xml 描述子中定義成服務端點介面 (SEI) 的 Stateless Session Bean 移轉至 J2EE 1.4 規格層次。

    如果 Session Bean 是當成 Web 服務端點使用,J2EE 1.4 規格便需要一個定義在 Stateless Session Bean 的 SEI。在 EJB JAR 檔的移轉期間,EJB 專案中的所有 Session Bean 都會使服務端點設為 EJB 專案之 webservices.xml 描述子中所用的名稱。以下是在移轉至 J2EE 1.4 規格層次之前和之後,EJB 專案的 Meta 資料內容範例。

    J2EE 1.3 EJB 專案:在移轉之前,以 Stateless Session Bean 為 Web 服務端點介面的 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>
    

    在移轉之前,上述範例中的 <service-endpoint-interface><service-impl-bean> 標示將 Stateless Session Bean "EchoEJB" 定義成 J2EE 1.3 規格層次之 Web 服務描述子中的服務端點。

    J2EE 1.4 EJB 專案:相同 Stateless Session Bean "EchoEJB" 的 EJB 部署描述子,含有移轉程序所建立的服務端點介面

    <?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 到 EJB 2.1 訊息驅動 Bean 的移轉作業。

    訊息驅動 Bean 是在 EJB 2.0 引進,用來支援處理來自 Java 傳訊服務 (JMS) 的非同步訊息。EJB 2.1 規格擴充了訊息驅動 Bean 的定義,使它能夠支援任何傳訊系統,而不只是 JMS。

    註:
    已從 EJB 2.0 規格層次移轉到 EJB 2.1 且部署到 WebSphere Application Server 第 6 版的訊息驅動 Bean,必須對 Java Connector Architecture (JCA) 1.5 資源配接器部署,而非對接聽器埠部署(如同在 WebSphere Application Server 第 5 版中一樣)。您必須使用「部署描述子編輯器」來變更 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 第 6 版的訊息驅動 Bean,必須對 Java Connector Architecture (JCA) 1.5 資源配接器部署,而非對接聽器埠部署。

    下列步驟說明如何變更 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 資源配接器新連線的使用者 ID 和密碼。

        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 包含一個 Description 物件,它有兩個屬性:languagevalue。J2EE 1.3 沒有這個 Description 物件;description 是鑑別限制的屬性。因此,當 Web 部署描述子的成品移轉至 J2EE 1.4 時,Description 物件的 value 會取自鑑別限制的 description 屬性。

    安全限制

    同樣地,在 J2EE 1.3 中,description 也是安全限制的屬性。在 J2EE 1.4 中,有一個新的 Description 物件,它含有 languagevalue 屬性。因此,Description 物件的 value 會取自安全限制的 description 屬性。

    Web 應用程式

    J2EE 1.3 規格層次之 ContextParam 物件的說明字串屬性已移至 J2EE 1.4 之 ParamValue 中的 Description 物件。

    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 服務(J2EE 1.3 至 J2EE 1.4)

    J2EE 1.4 規格透過新的 JAX-RPC 1.0 API 增加了 Web 服務的支援。

    JAX-RPC API 透過下列項目支援服務端點:

    J2EE 1.4 規格支援 J2EE 規格 (JSR 109) 的 Web 服務。JSR 109 定義了 Web 服務的部署需求並利用 JAX-RPC 程式設計模型。

    利用 J2EE 移轉精靈移轉的 Web 服務成品如下:

    移轉 Web 服務部署描述子

    移轉至 J2EE 1.4 規格層次的 J2EE 1.3 專案所包含的任何 Web 服務部署描述子都會從 JSR-109 1.0 版(用於 J2EE 1.3)移轉至 J2EE 1.4。

    JSR-109 1.0 版所定義的 Web 服務部署描述子是由 webservices.xml 檔、webservicesclient.xml 檔,以及 webservices.xml 和 webservicesclient.xml 檔所參照的所有 JAX-RPC 對映部署描述子所組成。 如同其他 J2EE 部署描述子,移轉作業會修改描述子中所包含的資訊結構,以符合 J2EE 1.4 規格。Web 服務部署描述子特有的一項結構變更是完整名稱表示方式的改變。 在 JSR-109 1.0 版中,完整名稱是使用兩個連續的元素 <namespaceURI><localpart> 來表示,其分別包含名稱的名稱空間 URI 和本端部分。J2EE 1.4 中的完整名稱是以 XMLSchema QName 類型(使用 XML 名稱空間)為基礎。

    以下提供移轉各 Web 服務部署描述子的進一步的詳細資料。


    J2EE 1.2 至 1.4 規格層次移轉

    J2EE 模組可以從 J2EE 1.2 規格層次移轉至 J2EE 1.4。這一節說明 J2EE 移轉精靈從 J2EE 1.2 移轉至 J2EE 1.4 規格層次的 J2EE 專案成品。

    如果需要使用 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) Entity Bean。

    在 J2EE 1.3 和 J2EE 1.4 規格層次之間,Entity Bean 並沒有任何變更。將 CMP Entity Bean 從 EJB 1.1 移轉至 EJB 2.1 規格層次的方式,與將 CMP Entity Bean 從 EJB 1.1 移轉至 EJB 2.0 相同。將儲存器管理 Entity 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) Entity Bean 還是 EJB 1.1 Bean。也就是說,CMP Entity Bean 不會轉換至 EJB 2.x。

    「J2EE 移轉」精靈會將 EJB 2.x 專案內的 Enterprise Bean 從 1.1 移轉至 2.x。(如果您選擇將 1.1 CMP Entity 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 專案支援 EJB 2.x Bean(不過,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 6.0 版中有下列限制:
      • 如果「EJB 查詢語言」的查詢所包含的 EJB 具有由其他 EJB 之關係所組成的索引鍵, 則這些查詢會顯示為無效的,且會導致部署時期發生錯誤。
      • IBM EJB 查詢語言支援使用各種方式延伸 EJB 2.x 規格,其中包括放寬某些限制、新增更多 DB2 功能的支援等等。 如果需要考慮跨越各種供應商資料庫或 EJB 部署工具的可攜性,請嚴格遵循 EJB 2.x 規格第 11 章說明的指示來小心撰寫所有「EJB 查詢語言」查詢。
    4. 對於任何 CMP 1.1 搜尋器,請傳回 java.util.Collection 而非 java.util.Enumeration
    5. 對於任何 CMP 1.1 Bean,請將 ejbCreate() 及程式碼所有其他位置中所出現的 this.field = value 改成 setField(value)
    6. 對於非應用程式的異常狀況,請更新您的異常狀況處理(回復行為):
    7. 針對應用程式異常狀況,更新您的異常狀況處理(回復行為):
    8. 更新特定應用程式預設值的任何 CMP 設定,使它成為在 ejbCreate 內(不使用廣域變數,因為 EJB 1.1 儲存器會先將所有欄位設為通用預設值,再呼叫 ejbCreate 來改寫任何先前的特定應用程式預設值)。

    移轉 EJB 1.1 關係的 EJB 參照

    當建立 EJB 1.1 關係時,會建立指向「遠端用戶端」視圖的 EJB 參照。在利用「J2EE 移轉」精靈來移轉 EJB 1.1 專案期間,會移除這些 EJB 1.1 關係的 EJB 遠端參照,用 EJB 本端參照來取代它們。使用者定義的 EJB 參照之本端參照必須手動重建。

    註:
    在 EJB 2.x 中,只有在 Bean 已定義了的「本端用戶端」視圖,且已建立了 EJB 2.x 關係的 EJB 本端參照時,才會建立 EJB 關係。

    如果是使用者定義的 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 包含一個 Description 物件,它有兩個屬性:languagevalue。J2EE 1.2 沒有這個 Description 物件;description 是鑑別限制的屬性。因此,當 Web 部署描述子的成品移轉至 J2EE 1.4 時,Description 物件的 value 會取自鑑別限制的 description 屬性。

    安全限制

    同樣地,在 J2EE 1.2 中,description 也是安全限制的屬性。在 J2EE 1.4 中,有一個新的 Description 物件,它含有 languagevalue 屬性。因此,Description 物件的 value 會取自安全限制的 description 屬性。

    Web 應用程式

    J2EE 1.2 規格層次之 ContextParam 物件的說明字串屬性已移至 J2EE 1.4 之 ParamValue 中的 Description 物件。

    J2EE 1.2 中的 TagLib 物件已移至 J2EE 1.4 中的 JSPConfig 物件。JSPConfig 物件屬於 1.2 中的 Web 根物件。


    Rational Application Developer 6.0 版中 J2EE 移轉精靈的變更

    Rational Application Developer 6.0 版中的 J2EE 移轉精靈(適用於所有 J2EE 規格層次之移轉作業)已有所變更。

    專案結構的移轉是選用的

    在 WebSphere Studio 5.1.x 版到 5.1.2 版,專案結構的移轉會和 J2EE 規格層次的移轉同時發生。在移轉 J2EE 規格層次時,專案結構的移轉並不是選用項目。

    在 Rational Application Developer 6.0 版的 J2EE 移轉精靈中,移轉專案結構是一個與移轉專案 J2EE 規格層次分開的選用選項。J2EE 規格層次和專案結構都可以獨立移轉。

    需要目標伺服器

    在 Rational Application Developer 6.0 版中,如果要將新的和現有的 J2EE 專案移轉至較高的 J2EE 規格層次,專案需要設定目標伺服器。 鎖定目標伺服器是如何在 6.0 版的 J2EE 專案上設定類別路徑的預設機制。 如果需要設定目標伺服器和使用 J2EE 移轉精靈的資訊,請參閱線上說明。


    第 5 章 移轉至 Rational Application Developer 6.0 版中的入口網站工具

    Portal Toolkit 5.0.2.2 版專案會藉由移轉 Portal Toolkit 工作區,或從 SCM(原始碼管理)系統載入專案,或利用專案交換特性匯入專案,而自動移轉至 Rational Application Developer 6.0 版入口網站工具。如果您要移轉舊版的 Portal Toolkit,您必須將 Portlet 專案匯出至 WAR 檔,再將 WAR 檔匯入 Rational Application Developer 6.0 版的入口網站工具中。

    在移轉入口網站應用程式之前,您必須先安裝 Rational Application Developer 6.0 版的入口網站工具特性。請參閱安裝手冊

    註:
    不支援 Portlet 專案與舊版相容。

    只支援利用 WebSphere Studio 5.1.2 版在 Portal Toolkit 5.0.2.2 版中建立的專案進行自動移轉。 請參閱第 1 章, 從 WebSphere Studio 5.1、5.1.1 或 5.1.2 移轉,以取得移轉的詳細資料。

    如果您的 Portlet 專案關聯於某個企業應用程式專案,您必須在 EAR 專案上設定適當的目標伺服器。 您可以在伺服器內容頁面(內容 -> 伺服器)中設定目標伺服器。

    在 Portal Toolkit 5.0.2.2 版專案的移轉期間,會進行一些其他變更:

    如果您要移轉舊版的 Portal Toolkit,您必須依照下列方式,將 Portlet 專案手動移轉至 Rational Application Developer 6.0 版的入口網站工具:

    1. 將現有的專案匯出至 WAR 檔: 在舊版 Portal Toolkit 中,將每個專案匯出到 WAR 檔以及程式檔。
      1. 用滑鼠右鍵按一下專案,選取匯出
      2. 選取 WAR 檔匯出程式檔,再按一下完成
    2. 匯入 Portlet WAR 檔:
      1. 在 Rational Application Developer 6.0 版的入口網站工具中,建立新的空白 Portlet 專案。
        1. 選取檔案 -> 新建 -> 專案 -> Portal -> Portlet 專案或 Portlet 專案 (JSR 168)
        2. 取消選取建立 Portlet
        3. 按一下顯示進階
        4. 如果您在匯入 WebSphere Portal 4.2 Portlet,請選取 2.2 作為 Servlet 版本。
        5. 選取 WebSphere Portal 5.0 版作為目標伺服器,再按一下完成
      2. 將 WAR 檔匯入這個新的空白 Portlet 專案。
        1. 選取匯入
        2. 選取 WAR 檔,指定您在上面匯出的 WAR 檔(在舊版中將專案匯出至 WAR 檔)。
        3. 選取新的空白 Portlet 專案。
        4. 選取改寫現有的資源,但不發出警告
        5. 選取改寫時刪除專案
    3. 刪除 TLD 檔:

      如果專案中有 Portlet TLD 檔,建議您刪除它。 否則,當您重新建置專案時,會出現一則警告訊息。 留下它可能會在 Portlet 專案部署到 WebSphere Portal 且 Portlet 的 TLD 檔與伺服器中的檔案不同時造成問題。

    4. 如果您移轉 WebSphere Portal 4.2 Portlet,您必須將這個移轉的 Portlet 專案移轉至 WebSphere Portal 5.x。

    如果需要將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版的相關資訊,請參閱將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版

    如果需要移轉 Portlet 專案中之 Faces 資源的相關資訊,請參閱更新 Portlet 專案中的 Faces 執行時期資源


    將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版

    Rational Application Developer 6.0 版不支援開發 WebSphere Portal 4.2 版 Portlet。 您必須將 WebSphere Portal 4.2 版 Portlet 專案移轉至 5.x 版。

    為了 WebSphere Portal 4.2 版而撰寫的大部分 Portlet,在 WebSphere Portal 5.x 版中,都可以照常執行。部分 Portlet 4.2.x API 現在標示為已棄用,但在 WebSphere Portal 5.x 版中仍可以使用。

    註:
    已移轉的 Portlet 應用程式專案與舊版不相容。

    如果要將 WebSphere Portal 4.2 版的 Portlet 應用程式移轉至 5.x 版,請執行下列步驟:

    1. 將 Portal 4.2 版 Portlet 專案移轉至 Portal 5.x 版 Portlet 專案:
      1. 用滑鼠右鍵按一下您要移轉的 Portlet 應用程式專案。
      2. 選取內容 -> Portlet API 來開啟 Portlet API 頁面。
      3. 從 Portlet API 層次下拉清單中,選取 WebSphere Portal 5.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 5.x 版而設計的 Portlet 應用程式應該符合 J2EE 層次 1.3 規格。
      註:
      將企業應用程式專案移轉至 J2EE 1.3 之前,請先閱讀第 4 章, 移轉 J2EE 專案。如果需要使用 J2EE 移轉精靈的相關資訊,請參閱線上說明。
      1. 如果移轉的 Portlet 專案只關聯於企業應用程式專案,請執行下列動作:
        1. 關閉工作台中的所有編輯器。
        2. 用滑鼠右鍵按一下已移轉的 Portlet 專案的相關企業應用程式專案。
        3. 選取移轉 -> J2EE 移轉精靈,再按下一步
        4. 選取 J2EE 1.3 版WebSphere Portal 作為目標伺服器。
        5. 按一下完成
      2. 如果有其他 Portlet 專案關聯於企業應用程式專案,您必須移除已移轉的 Portlet 專案,將它新增至另一個企業應用程式專案中。
        1. 從企業應用程式專案中移除已移轉之 Portlet 專案的模組。
          1. 展開企業應用程式專案,選取部署描述子。
          2. 選取開啟工具 -> 部署描述子編輯器
          3. 選取模組標籤。在編輯器的「模組」頁面中,選取已移轉之 Portlet 專案的 WAR 檔。
          4. 按一下移除
          5. 選取檔案 -> 儲存來儲存變更。
        2. 建立新的企業應用程式專案,將 Portlet 專案新增至其中。
          1. 選取檔案 -> 新建 -> 專案
          2. 選取顯示所有精靈勾選框。
          3. 展開 J2EE,選取企業應用程式專案
          4. 填寫專案名稱欄位,選取 J2EE 1.3 版WebSphere Portal 作為目標伺服器,再按下一步
          5. EAR 模組專案頁面中,選取已移轉的 Portlet 專案,按一下完成

    這時會將 Portlet 專案移轉至 WebSphere Portal 5.x 版。


    更新 Portlet 專案中的 Faces 執行時期資源

    原來在 WebSphere Studio Application Developer 5.1.2 版中所附的 JavaServer Faces 執行時期資源, 在 Rational Application Developer 6.0.1 版已更新。 如果您要繼續在以這個舊產品版本的 Portal Toolkit 5.0.2.2 所建立的 Portlet 專案上進行開發,建議您將 Faces 執行時期資源更新到最新的層次。

    在 Rational Application Developer 6.0.1 版中,當匯入的 Portlet 專案或開啟工作區含有過期的資源時,Faces 執行時期資源即會自動更新。 在匯入以 WebSphere Studio Application Developer 5.1.x 版的 Portal Toolkit 5.0.2.2 所建立的 Portlet 專案至 Rational Application Developer 6.0.1 版,系統會提示您將 Faces 執行時期資源更新到最新的層次。

    自動更新執行時期資源

    若要自動更新 Portlet 專案的 Faces 執行時期資源,請執行下列動作:

    1. 從 WebSphere Studio Application Developer 5.1.x 版匯入含有 Faces 內容的 Portlet 專案。 這時會開啟「專案移轉」視窗。
      註:
      如果「專案移轉」視窗未開啟,您的自動建置喜好設定可能已停用。請在專案瀏覽器中, 用滑鼠右鍵按一下 Portlet 專案,然後選取建置 -> 專案;重新建置專案的程序即會開啟「專案移轉」視窗。
    2. 如果工作區中有其他 Portlet 專案含有 Faces 內容,請勾選將這個選項套用到任何其他需要升級的專案,則所有的 Portlet 專案都會更新。
    3. 按下列其中一項:
    4. 若要更新 Portlet 特定的 Faces 執行時期資源、jsf-portlet.jar 和 jsf-wp.jar,您需要遵循以下的手動更新步驟。
    註:
    如果您建立了含有「Faces 用戶端」元件的 Faces JSP, 您必須將「Faces 用戶端」元件執行時期資源個別更新到最新的層次。請參閱更新 Web 專案中的 Faces 用戶端執行時期資源

    手動更新執行時期資源

    若要手動更新 Portlet 專案的 Faces 執行時期資源,請執行下列動作:

    1. 將含有 Faces 內容的現有 Portlet 專案匯入 Rational Application Developer 6.0.1 版工作區中。
    2. 在第二個頁面中選取 Faces Portlet 選項,來建立名稱為 JSFP601 的新 Portlet 專案。這個專案只會用來作為最新執行時期資源的來源; 其在更新完成之後即可刪除。
    3. 在專案瀏覽器中,用滑鼠右鍵按一下 JSFP601 專案,然後從功能表中選取內容
    4. 按一下 Web 專案特性,然後選取新增 Portlet 專案的 Faces 用戶端組織架構,然後按一下確定
    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 6.0 版中,產品所包含的 WebSphere Application Server 測試環境已變更,與舊版的 WebSphere Studio Application Developer 所包含者有所不同。

    以下是 Rational Application Developer 6.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 4.x 版 AE WebSphere Application Server 5.x 版 Base WebSphere Application Server Express 5.x WebSphere Application Server 5.x 版 Portal WebSphere Application Server 6.0 版
    WebSphere Studio Application Developer 5.1 版 4.0.6 版 5.0.2 版 5.0.2 版 N/A N/A
    WebSphere Studio Application Developer 5.1.1 版 4.0.7 版 + PQ78374 5.0.2 版 + PQ78374 +PQ78419,5.1 版 5.0.2 版和 5.1 版 N/A N/A
    WebSphere Studio Application Developer 5.1.2 版 4.0.7 版 + PQ78374 5.0.2 版 + PQ78374 + PQ78419,5.1.0.3 版 5.0.2 版和 5.1.0.3 版 5.0.2.3 版 Base + WebSphere Portal 5.0.2.1 版 N/A
    Rational Application Developer 6.0 版 N/A 5.0.x 版,5.1.1 版 5.0.2 版和 5.1.1 版 V5.0.2.6 Base + WebSphere Portal 5.0.2.2 版、5.1.1 版 Base + WebSphere Portal 5.1 6.0 版

    版權和注意事項