第 1 章 從 WebSphere Studio 5.1、5.1.1 或 5.1.2 移轉
第 2 章 從 Rational Application Developer 6.0 版更新 Web 專案的 Faces 執行時期資源
第 3 章 從 Rational Application Developer 6.0 版更新 Portlet 專案的 Faces 執行時期資源
第 5 章 移轉至 Rational Application Developer 6.0 版中的入口網站工具
這份文件提供從 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 版移轉,請執行下列動作:
附註:在工作區移轉期間,會開啟問題對話框,其中含有下列訊息:無法還原工作台佈置。原因:還原工作台時,發生問題。這個錯誤訊息不會影響工作區的順利移轉。 請按一下錯誤對話框中的詳細資料按鈕來記下無法還原的視景名稱,再按一下確定來關閉對話框。
如果要還原視景,請執行下列動作:
附註:
重要事項:
當您第一次在 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 應用程式與舊版不相容。
如果您沒有執行下列中的任何動作,利用專案交換,從 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 版相容。 請勿直接編輯或刪除這項資訊。
只要這個相容性 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 版專案之後的手動步驟:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/ org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
<classpathentry kind="con" path="com.ibm.wtp.server.java.core.container/ com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
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 版所建立的企業應用程式專案中,或從移轉自舊版 WebSphere Studio 的企業應用程式專案中,完全移除與 WebSphere Studio Application Developer 5.1.x 版的相容性。只有在確定企業應用程式專案應不再具有與 5.1.x 版交互作業或相容的功能時,您才應停用與 WebSphere Studio 5.1.x 版的相容性。
如果要移除與 WebSphere Studio Application Developer 5.1.x 版的相容性,請執行下列動作:
執行「移除相容性」作業之後,企業應用程式專案以及企業應用程式專案下的所有巢狀模組和公用程式專案都不再相容於 WebSphere Studio Application Developer 5.1.x 版。
原來在 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 執行時期資源,請執行下列動作:
手動更新執行時期資源
若要手動更新 Web 專案的 Faces 執行時期資源,請執行下列動作:
<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>
<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>
原來在 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 用戶端執行時期資源,請執行下列動作:
手動更新執行時期資源
若要手動更新 Web 專案的 Faces 用戶端執行時期資源,請執行下列動作:
將含有 Faces 用戶端元件之專案的目標伺服器從 WebSphere Application Server 5.1 版改成 6.0 版時,可能會發生問題。
將含有 Faces 用戶端元件之專案的目標伺服器從 WebSphere Application Server 5.1 版改成 6.0 版時,可能會發生兩個問題:
比方說,如果現行頁面有稱為 ACCOUNT 的用戶端資料,且您的內容檔有類似下列中的項目:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
您應該從項目中刪除 com\\ibm\\dynwdo4jsmediators/orders.emap。 這時項目應該看起來如下:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
升級至自動化的 Diff 處理常式和處理器
Diff 處理器和處理常式現在會自動產生。如果您在 WebSphere Studio 5.1.x 版中撰寫 Faces 用戶端元件的 Diff 處理常式和處理器, 建議您捨棄該程式碼,改用自動產生的處理器和處理常式:
String Diff = getClientData1().getDiffStr(); if (DiffProcessor.Synch(getRoot(), Diff) == true) return ""; return "failure";
保留對 5.1.x 版所撰寫的自訂 Diff 處理常式和處理器
雖然不建議您這麼做,但如果您決定需要保留 5.1.x 版的 Diff 處理常式和處理器, 您必須加以修改才能在 6.0 版中運作,因為 DiffHandler 介面和 DiffInfo 類別已變更。
find 和 getId 方法是在內部供產生的 DiffHandler 使用。對於您的自訂 DiffHandlers,您可以只是為了符合介面規格而實作空的方法。 組織架構不會呼叫這些方法。
現在,DiffHandler 介面是:
public interface DiffHandler { public void handle(DiffInfo Diff) throws DiffException, Exception; public Object find (DiffInfo Diff) throws DiffException, Exception; public String getId (DiffInfo Diff, boolean Original); }
現在,DiffInfo 類別如下:
public class DiffInfo { public char getCrud() public DataObject getCurrent() public String getEClassName() public DataObject getOriginal() public String getPropertyName() public DiffInfo getParent() }
6.0 版之 Faces 用戶端元件的變更
針對 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 異常狀況。
請遵循下列步驟在 6.0 版中,更正 WebSphere Studio 5.1.x 版建立之 Struts Web 專案的部署描述子:
<param-value>WEB-INF/struts-config.xml</param-value>(這位於 <servlet></servlet> 標示內)
to
<param-value>/WEB-INF/struts-config.xml</param-value>。
當 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,請執行下列動作:
將 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,請執行下列動作:
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 除錯階段作業。如果要執行這個動作,您可以先執行下列動作之一:
如果您在 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 與另一個匯入的類型衝突
您可以依照下列方式來更正這些類型衝突錯誤:
import 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 |
這些是 Enterprise Generation Language (EGL) 在 Rational Application Developer 中的新保留字。
下列為新的保留字:
在利用這些單字作為變數或組件名稱的 6.0 版工作區中匯入和建置的 WebSphere Studio 5.1.x 版 EGL 程式,都會標示下列訊息:IWN.SYN.2002.e 39/2 輸入 "variableName" 語法錯誤。您可以重新命名變數來更正這個問題。
原來在 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 用戶端執行時期資源,請執行下列動作:
手動更新執行時期資源
若要手動更新 Web 專案的 Faces 和 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 用戶端執行時期資源,請執行下列動作:
手動更新執行時期資源
若要手動更新 Portlet 專案的 Faces 和 Faces 用戶端執行時期資源,請執行下列動作:
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 移轉精靈的完整詳細資料。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 服務從 J2EE 1.3 移轉至 J2EE 1.4 時,J2EE 移轉精靈不會移轉安全 Web 服務。安全 Web 服務的移轉作業需要手動步驟。
在 J2EE 移轉之後,您必須依照下列方式,將安全連結和延伸規格檔手動移轉至 J2EE 1.4:
J2EE 專案可以從 J2EE 1.3 移轉至 J2EE 1.4 規格層次。這一節說明 J2EE 移轉精靈從 J2EE 1.3 移轉至 J2EE 1.4 的各類型 J2EE 專案的成品。
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 訊息驅動 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>
已從 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 配接器:
輸入用來部署這個訊息驅動 Bean 之 J2C 啟動規格的 JNDI 名稱。這個名稱必須符合您定義給 WebSphere Application Server 的 J2C 啟動規格名稱。
用來鑑別 JCA 資源配接器連線之 J2C 鑑別別名的名稱。J2C 鑑別別名會指定用來鑑別建立 JCA 資源配接器新連線的使用者 ID 和密碼。
輸入訊息驅動 Bean 用來在 JNDI 名稱空間中查閱 JMS 目的地的 JNDI 名稱。
當 J2EE 1.3 層次的 Web 專案移轉至 J2EE 1.4 時,J2EE 移轉精靈會移轉 Web 部署描述子的成品。
會移轉的 Web 應用程式成品如下:
鑑別限制
J2EE 1.4 包含一個 Description 物件,它有兩個屬性:language 和 value。J2EE 1.3 沒有這個 Description 物件;description 是鑑別限制的屬性。因此,當 Web 部署描述子的成品移轉至 J2EE 1.4 時,Description 物件的 value 會取自鑑別限制的 description 屬性。
安全限制
同樣地,在 J2EE 1.3 中,description 也是安全限制的屬性。在 J2EE 1.4 中,有一個新的 Description 物件,它含有 language 和 value 屬性。因此,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 根物件。
J2EE 移轉精靈會將 J2EE 連接器架構 (JCA) 1.0 描述子的成品移轉至 JCA 1.5。 移轉後的成品會和 ResourceAdaptor 物件的元素相關,因為有兩個新物件(OutboundResourceAdaptor 和 ConnectionDefinition)已加入連接器專案之 J2EE 1.4 規格層次的 ResourceAdaptor 物件中。
已移轉之元素的對映說明如下。
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 服務部署描述子的進一步的詳細資料。
webservices.xml 部署描述子存在於包含 J2EE Web 服務的 Web 專案和 EJB 專案中。<wsdl-port> 元素和 <soap-header> 元素都包含完整名稱, 且其內容會移轉成 J2EE 1.4 格式。
比方說,如果 <wsdl-port> 在移轉之前的表示法如下:
<wsdl-port> <namespaceURI>http://addressbook.webservice</namespaceURI> <localpart>AddressBook</localpart> </wsdl-port>
移轉之後,<wsdl-port> 的表示法如下:
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
"pfx" 字首用來作為所有已移轉的完整名稱之名稱空間字首。
webservicesclient.xml 部署描述子在包含 J2EE Web 服務用戶端的 J2EE 1.3 Web 專案、EJB 專案及應用程式用戶端專案中。在從 J2EE 1.3 移轉至 1.4 的期間,webservicesclient.xml 的內容會移轉並移至專案的部署描述子。所發生的程序如下:
<service-qname> 元素和 <soap-header> 元素都包含完整名稱,且其內容會移轉成 J2EE 1.4 格式。比方說,如果 <service-qname> 在移轉之前的表示法如下:
<service-qname> <namespaceURI>http://addressbook.webservice</namespaceURI> <localpart>AddressBookService</localpart> </service-qname>
移轉之後,<service-qname> 的表示法如下:
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
"pfx" 字首用來作為所有已移轉的完整名稱之名稱空間字首。
webservices.xml 和 webservicesclient.xml 部署描述子都可以參照一或多個 JAX-RPC 對映部署描述子。
在 webservices.xml 檔中,這些參照是包含在每個 <webservice-description> 元素之下的 <jaxrpc-mapping-file> 元素中。在 webservicesclient.xml 檔中,這些參照是包含在每個 <service-ref> 元素之下的 <jaxrpc-mapping-file> 元素中。
在從 J2EE 1.3 移轉至 1.4 的期間,webservices.xml 和 webservicesclient.xml 中所有的 JAX-RPC 對映部署描述子都會被移轉。移轉作業包括將所有完整名稱移轉成 J2EE 1.4 格式(請參閱上節的 webservices.xml 和 webservicesclient.xml,以取得移轉後的完整名稱範例)。
J2EE 模組可以從 J2EE 1.2 規格層次移轉至 J2EE 1.4。這一節說明 J2EE 移轉精靈從 J2EE 1.2 移轉至 J2EE 1.4 規格層次的 J2EE 專案成品。
如果需要使用 J2EE 移轉精靈的詳細資料,請參閱第 4 章, 移轉 J2EE 專案。
這一節說明將 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 規格層次時,需要執行下列步驟:
您可以利用 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 1.1 轉換至 EJB 2.x 的專案,您必須採取一些步驟,將現有的 EJB 1.1 程式碼移轉至 EJB 2.x。
當建立 EJB 1.1 關係時,會建立指向「遠端用戶端」視圖的 EJB 參照。在利用「J2EE 移轉」精靈來移轉 EJB 1.1 專案期間,會移除這些 EJB 1.1 關係的 EJB 遠端參照,用 EJB 本端參照來取代它們。使用者定義的 EJB 參照之本端參照必須手動重建。
如果是使用者定義的 EJB 參照,就不用「J2EE 移轉」精靈來進行任何移轉。不過,請遵循下列步驟來設定本端參照:
在利用 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 1.2 Web 專案移轉至 J2EE 1.4 規格層次時,J2EE 移轉精靈會移轉 Web 部署描述子的成品。
會移轉的 Web 應用程式成品如下:
鑑別限制
J2EE 1.4 包含一個 Description 物件,它有兩個屬性:language 和 value。J2EE 1.2 沒有這個 Description 物件;description 是鑑別限制的屬性。因此,當 Web 部署描述子的成品移轉至 J2EE 1.4 時,Description 物件的 value 會取自鑑別限制的 description 屬性。
安全限制
同樣地,在 J2EE 1.2 中,description 也是安全限制的屬性。在 J2EE 1.4 中,有一個新的 Description 物件,它含有 language 和 value 屬性。因此,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 移轉精靈(適用於所有 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 移轉精靈的資訊,請參閱線上說明。
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 版的入口網站工具特性。請參閱安裝手冊。
只支援利用 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 版的入口網站工具:
如果專案中有 Portlet TLD 檔,建議您刪除它。 否則,當您重新建置專案時,會出現一則警告訊息。 留下它可能會在 Portlet 專案部署到 WebSphere Portal 且 Portlet 的 TLD 檔與伺服器中的檔案不同時造成問題。
如果需要將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版的相關資訊,請參閱將 WebSphere Portal 4.2 版 Portlet 移轉至 5.x 版。
如果需要移轉 Portlet 專案中之 Faces 資源的相關資訊,請參閱更新 Portlet 專案中的 Faces 執行時期資源。
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 版中仍可以使用。
如果要將 WebSphere Portal 4.2 版的 Portlet 應用程式移轉至 5.x 版,請執行下列步驟:
這時會將 Portlet 專案移轉至 WebSphere Portal 5.x 版。
原來在 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 執行時期資源,請執行下列動作:
手動更新執行時期資源
若要手動更新 Portlet 專案的 Faces 執行時期資源,請執行下列動作:
<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>
<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>
在 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 測試環境層次。
| 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 版 |