このトピックでは、ページ フローに関するアップグレードでの変更の詳細について説明します。
バージョン 8.1 からアップグレードされるアプリケーションに対して行われる変更の詳細なリストについては、「WebLogic Workshop 8.1 からバージョン 10.x へのアップグレード時における変更点」を参照してください。
アップグレード ツールを使用してアップグレードを実行する場合、バージョン 8.1 の NetUI JSP タグをバージョン 10.x の NetUI JSP タグに置き換えるかどうかを選択できます。バージョン 10.x の NetUI JSP タグは、バージョン 8.1 のタグと比べて機能が強化されています (NetUI タグは、Workshop バージョン 10.x の新しい Web プロジェクトではデフォルトです)。デフォルトの動作では、バージョン 8.1 のタグは現在の NetUI タグに置き換えられません。代わりにデフォルトでは、バージョン 8.1 のタグはバージョン 8.1 のタグのまま、バージョン 10.x のサーバと互換性のあるバージョンにアップグレードされます。
注意 : JSP ページでは、互換性のあるバージョン 8.1 のタグと 10.x のタグを組み合わせて使用することができます。ただし、このような併用がサポートされるのは、アップグレードの結果、一部のバージョン 8.1 のタグに対応する 10.x タグがないことが原因でタグが併用される場合のみです。
タグに関する決定を行うことで、アプリケーションの JSP 部分にさまざまな影響が出ます。選択の前に、以下のことを考慮してください。
- 通常、現在のタグを使用する場合、現在のタグへの移行には 2 段階のプロセス (互換性のあるバージョン 8.1 のタグへのアップグレードと、その後の現在のタグへの移行) が必要になる。この 2 段階のプロセスにより、アップグレードされたアプリケーションを現在の技術に移行する前に確実にバージョン 10.x のサーバ上で実行できます。また、新しい JSP ページの作成や既存の JSP ページのアップグレードなどのアプリケーションの修正を行い、後でアプリケーションを部分的に現在のモデルに移行できます。
- アプリケーションがメンテナンス モードの場合は、バージョン 8.1 のタグを現在のタグに置き換えないことを検討する。互換性のあるバージョン 8.1 のタグにアップグレード (つまり、デフォルト動作を選択) したほうが、バージョン 10.x のアプリケーションの起動および実行が速くなることがあります。
- アプリケーションがまだ開発モードの場合は、バージョン 8.1 のタグを現在のタグに置き換えることを検討する。拡張された 10.x のタグの利点は数多くあり、完全に移行するだけの価値はあるはずです。
アップグレード時にタグが変更される
アプリケーションのアップグレード時にバージョン 8.1 のタグを 10.x のタグに置き換えることを選択すると、バージョン 8.1 のタグの大部分は、簡単に特定できる、対応する 10.x のタグに置き換えられます。こうした対応予測には、次の表に示すような例外があります。
 |
 |
 |
||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||
 |
|
 |
アップグレード時に属性が変更される
JSP タグの属性の中には、アップグレード時に新しい属性に移行されたり、単純に削除されたりするものがあります。次の表に、予測される変更を示します。
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
アプリケーションのアップグレード時には、バージョン 8.1 の NetUI JSP タグをアップグレードするかどうかの確認を求められます。アップグレードを選択するかどうかに関係なく、アップグレードされたアプリケーションのデフォルトの式言語は、新しいアプリケーションで使用されるバージョンではなく下位互換性のあるバージョンになります。その理由は、下位互換性のあるバージョンには寛容性があり、完全にアップグレードする準備ができるまで既存のコードを使用できるからです。現在の JSP タグ技術への完全なアップグレードを選択した場合には、デフォルトの式言語を現在のタグがサポートされているバージョンに変更する必要があります。
ページに JSP タグを追加すると、バージョン 10.x の式言語が使用されます。そのときまでは、引き続き下位互換性のある式言語をデフォルトとして使用する必要があります。詳細については、「JSP タグで使用されるデフォルトの式言語の変更」を参照してください。
注意 : 一般的には、バージョン 8.1 の NetUI タグは非推奨であると考えてください。新しいコードではバージョン 10.x の NetUI JSP タグを使用しなければなりません。
現在の JSP タグを使用するように JSP ページを完全にアップグレードした場合は、デフォルトの式言語を下位互換性のあるバージョンからバージョン 10.x に変更する必要があります。
注意 : この変更を行う前に、コードの変更が必要になる場合があることに注意してください。
プロジェクトの beehive-netui-config.xml ファイルを編集することで、デフォルトの式言語を変更できます。このファイルは、次のようなパスに配置されています。
WORKSPACE_HOME\PROJECT_HOME\web\WEB-INF\beehive-netui-config.xml
デフォルトの言語として指定できる設定には、netuiel (JSP 2.0 式言語) および compat-netuiel (バージョン 8.1 の NetUI 式言語) があります。デフォルトを JSP 2.0 式言語に変更するには、次の記述を含むようにファイルを変更します。
<expression-languages> <default-language>netuiel</default-language> .... </expression-languages>
バージョン 10.x の NetUI JSP タグで式言語をサポートするためのコードの変更
バージョン 8.1 の NetUI JSP タグを 10.x の NetUI JSP タグにアップグレードすることを選択した場合には、現在のタグで使用される式言語をサポートするように JSP コードで式を変更する必要があります。以下では、アップグレード時にツールによって行われる変更と、場合に応じて非 JSP コードに対して自ら行う必要のある変更について説明します。
アップグレード時に式が変更される
以下の変更は、アップグレード時に式に対して行われます。
- dataSource 属性の使用が、dataSource="{actionForm.name}" から dataSource="actionForm.name" に変更される。
- 形式 {expression} の式が、${expression} に変更される (dataSource 属性は除く)。
- バージョン 8.1 のバインディング コンテキストが、次の表のとおりに変更される。
8.1 のバインディング コンテキスト 10.x の の暗黙的オブジェクト コメント url param JSP 2.0 の暗黙的オブジェクト名に変更される。 request requestScope JSP 2.0 の暗黙的オブジェクト名に変更される。 application applicationScope JSP 2.0 の暗黙的オブジェクト名に変更される。 session sessionScope JSP 2.0 の暗黙的オブジェクト名に変更される。 pageContext pageScope JSP 2.0 の暗黙的オブジェクト名に変更される。 actionForm actionForm pageInput pageInput container container pageFlow pageFlow globalApp globalApp bundle bundle sharedFlow 新しいバインディング コンテキスト。 backing JavaServer Faces で使用される、新しいバインディング コンテキスト。
パブリック データ メンバーにバインドするには変更が必要になる
バージョン 8.1 の NetUI JSP タグをバージョン 10.x の NetUI JSP タグにアップグレードする場合には、パブリック メンバーによって保持されるデータをバインディング タグにエクスポーズする方法の変更が必要になる場合があります。バージョン 8.1 ではパブリック フィールドへの式コードのバインディングがサポートされていましたが、バージョン 10.x では式はパブリック アクセサにしかバインドできません。
つまり、アップグレード ツールでは JSP タグで使用される式言語構文はアップグレードされますが、クラスへのアクセサが必要となる場所にアクセサを追加する処理は行われません。現在の JSP タグに完全にアップグレードするには、パブリック フィールドが使用されていた場所に get* アクセサおよび set* アクセサを手動で追加する必要があります。
JSP 2.0 式言語では以下の予約語が使用されます。コードではこれらの予約語を識別子として使用しないでください。
and eq gt true instanceof
or ne le false empty
not lt ge null div mod
式言語コードにプロパティをエクスポーズするように設計されたアクセサの名前に予約語を含めることで、その予約語を使用できます。たとえば、次のコードは empty プロパティをエクスポーズするように設計されたものです。
public String empty;
public String getEmpty() {return empty;}
JSP ページでは、当然ながら、予約語である「empty」をプロパティ名として使用することになります。
<netui:content value=?${pageFlow.empty}? defaultValue=?NO VALUE?/>
代わりに、「getEmptyVal」など結果としてメソッド名になる命名方式を使用して、pageFlow.emptyVal を使用してそれらにバインドします。
式言語の詳細については、J2EE 1.4 チュートリアルにある「Expression Language」を参照してください。
バージョン 8.1 とは異なり、バージョン 10.x では、ページ フローで使用されるフォーム (現在は非推奨になっている FormData クラスを拡張したものなど) にはデフォルト コンストラクタが含まれていなければならないという要件があります。
コードのアップグレード後にデフォルト コンストラクタを追加することで、この変更に対応できます。
バージョン 8.1 の XMLBeans では XQuery 草案 16 が使用されていましたが、バージョン 10.x では草案 23 が使用されています。アップグレード ツールでは通常、XQuery 式を実行する XMLBeans コードは更新されますが、JSP ファイル内のコードは更新されません。旧バージョンの実装に基づいて機能するコードに対して、必要な変更を手動で行う必要があります。
詳細については、「アップグレードされた XQuery 実装をサポートするための XQuery の使用の更新」を参照してください。
ページ フロー Controller ファイルでは、型のインポートの外側で型名が完全修飾されている場合、その型のパッケージはバージョン 10.x で使用されるパッケージにアップグレードされません。たとえば次のアップグレード後のコードでは、Forward のパッケージは com.bea.wlw.netui.pageflow から org.apache.beehive.netui.pageflow にアップグレードされていません。
/**
* @jpf:action
* @jpf:forward name="begin" path="Begin.jsp"
*/
@Jpf.Action(forwards = {
@Jpf.Forward(name = "begin",
path = "Begin.jsp")
})
public Forward begin()
{
return new com.bea.wlw.netui.pageflow.Forward("begin");
}
エラーはソース コードで強調表示されます。Workshop のクイック フィックス機能を使用して、型を同一名の正しい型に置き換えることで修正できます。検索と置き換えを行って修正することもできます。
バージョン 8.1 で NetUI タグを拡張してカスタム JSP タグを作成した場合、それらのタグは Workshop ツールではアップグレードされません。NetUI タグの拡張はサポートされていませんでした。NetUI タグを現在のタグに移行しないことを選択した場合には、それらのタグはアプリケーション内でビルドされますが、想定どおりに機能しないおそれがあります。
同様に、バージョン 10.x での JSP タグの拡張もサポートされていません。
状態トラッキング API での変更を反映するためのコードの更新
バージョン 10.x では、特定の状況で null ではなく IllegalStateException を返すように NetUI API のいくつかのメソッドが変更されています。これは、要求されている戻り値が実際に null なのか、トラッキングされていないために単に不明なのかに関係なく null が返されていたバージョン 8.1 に対する改良です。
true を返すように alwaysTrackPreviousAction メソッドをページ フロー コントローラでオーバーライドすることで、IllegalStateException の処理を回避できます。ただし、これによりアプリケーションのパフォーマンスが低下するおそれがあります。次に例を示します。
protected boolean alwaysTrackPreviousAction()
{
return true;
}
変更されているメソッドは次のとおりです。
- getPreviousActionURI
- getPreviousActionInfo
- getCurrentPageInfo
- getPreviousPageInfo
- getPreviousFormBean
- getCurrentForwardPath
- getPreviousForwardPath
以下に、変更に関係する詳細な状況を示します。
- この変更は、現在のページ フローで
@jpf:forwardがreturn-to="previousAction"属性とともに使用されていない場合にのみ関係する。 - alwaysTrackPreviousAction が
trueを返すようにオーバーライドされていない場合は、バージョン 10.x のメソッドによって java.lang.IllegalStateException が返される。 - alwaysTrackPreviousAction が true を返すようにオーバーライドされている場合は、バージョン 10.x のメソッドによって、要求されている値、またはその値が実際に null の場合には
nullが返される。
バージョン 10.x では、ページ フロー内のカスタム コントロールで外部コールバックを受信できません。バージョン 8.1 では、カスタム コントロール内にネストされているコントロール (サービス コントロールなど) からのコールバックを、そのカスタム コントロールで受信するコードを記述できました。カスタム コントロールからポーリング インタフェースをエクスポーズすることで、ページ フロー コードでコールバックから受信した応答を取得できました。この機能はバージョン 10.x ではサポートされていません。
アップグレードされたコード内でカスタム コントロールを Web サービスに置き換えることで、この機能の代わりとすることができます。バージョン 8.1 の該当する機能と、バージョン 10.x において考えられる回避策の詳細については、「ページ フローでコントロール コールバックをサポートする方法」を参照してください。
バージョン 10.x では、ランタイムで必要になるアーティファクトを生成するコンパイル時のアセンブル プロセスが、一部のコントロールで必要になっています。サービス コントロール、EJB コントロール、およびタイマー コントロールはこれに該当します。
このアセンブル プロセスは、これらのコントロールが Java ファイル内で参照されている場合にのみ、これらのコントロールに対してトリガされます (JSP ページからのみ参照されるコントロールは事実上除く)。アップグレードされたコードでは、コントロールを Java ファイルから参照することで、バージョン 8.1 からの変更に対応できます。
この参照に最適な場所はページ フロー コントローラ ファイルです (アプリケーションにコントローラがない場合には、アプリケーションとともにコンパイルされる別の Java ファイルに参照を追加できます)。参照するには、JSP ページで使用されているコントロール クラスを指定する org.apache.beehive.controls.api.bean.ControlReferences アノテーションを追加します。次に、1 つのコントロールを参照する例を示します。
@ControlReferences(value={mycontrols.MyServiceControl.class})
public class Controller extends PageFlowController {
...
}
バージョン 8.1 では、jpf:validation-error-forward アノテーションおよび jpf:forward アノテーションの name 属性に対して同じ名前を使用できました。バージョン 10.x では同じ名前は使用できなくなっています。 たとえば、次のようなバージョン 8.1 のコードを使用することができました。ここでは name 属性の値として「failure」が 2 回使用されています。
/**
* @jpf:action
* @jpf:forward name="success" return-action="addProfileDone"
* @jpf:forward name="failure" path="addClient.jsp"
* @jpf:validation-error-forward name="failure" return-to="currentPage"
*/
protected Forward addClientProfile(MaintainIndividualProfileForm form)
{
...
}
このコードに対応するアップグレードされたコード (Jpf.Forward アノテーションと Jpf.Action validationErrorForward 属性のコード) によって、バージョン 10.x ではビルド エラーが生成されます。 同じにならないように属性値の一方または両方を変更することで、この変更に対応できます。
バージョン 8.1 では、コントローラ ファイル (Controller.jpf) と JSP ファイルを同じディレクトリに配置できるプロジェクト階層がサポートされていました。これはバージョン 10.x ではサポートされていません。
たとえば、アップグレード時にページ フローに対して次のような階層の変更が発生します。
バージョン 8.1 :
webapp/ Controller.jpf index.jsp
バージョン 10.x (アップグレード後)
webapp src Controller.java web index.jsp
バージョン 8.1 のスタイルは「共存」と呼ばれます。バージョン 10.x (アップグレードされたアプリケーションも含む) では、JAVA ソース ファイルと JSP は別のディレクトリに保持されます。myPageFlow という新しいページ フローを作成すると、myPageFlow という 2 つのディレクトリ (一方は JAVA ソース コード用、もう一方は JSP 用) が使用されます。次に、簡単な例を示します。
webapp src myPageFlow myPageFlowController.java Controller.java WebContent index.jsp myPageFlow index.jsp page1.jsp other JSPs
バージョン 9.2 の IDE では、HTML 開始タグ内で変数宣言が行われるコードに対してエラーが誤って表示されます。実際には実行時にコードは有効です。たとえば、次のアンカー タグでは String 変数を使用している <%=s%> コードが IDE によって未解決として示されますが、実際には有効です。
<a href="<%!String s="test"; %><%=s%>">Test</a>
このエラーの誤表示は、<render:getJspUri>、<render:getSkinPath> などの、Java 変数を設定する WebLogic Portal のタグにも適用されます。
バージョン 8.1 からアップグレードされたコードでこの問題を回避するには、次のように変数宣言を開始タグの外側の行に移動します。
<%! String s="test"; %> <a href="<%=s%>">Test</a>
com.bea.wlw.netui.util.XMLString のインポートおよび使用の非サポート (アップグレード不可)
この XMLString クラスは、バージョン 10.x には含まれていません (XMLBeans の org.apache.xmlbeans.XmlString と混同しないようにしてください)。アップグレードされたコードでこの型がインポートされていると、コンパイル エラーが生成されます。バージョン 8.1 ではこのクラスは、バージョン 10.x から削除された XScript 式言語とともに使用されていました。
Web アプリケーションをアップグレードすると、ページ フロー コントローラのソース フォルダがデフォルトの場所に戻ることがある
Beehive NetUI ファセットが含まれている一部のバージョン 9.2 Web プロジェクトでは、[関連ファイル モデル] の設定値が保持されない場合があります。特に、このようなプロジェクトに複数のソース フォルダが含まれ、[ページ フロー コントローラ] プロパティ パネルがデフォルト以外のソース フォルダに設定されている場合、プロジェクトをアップグレードすると、この値がデフォルトに戻ります。
Beehive NetUI ファセットと JSF ファセットの両方が含まれているプロジェクトでは、同じ状況が [プロジェクト｜プロパティー｜関連ファイル モデル｜JSF バッキング ファイル] プロパティで発生する場合がある。
この値を変更するには、[プロジェクト｜プロパティ｜関連ファイル モデル｜ページ フロー コントローラ] を選択し、目的のソース フォルダを選択します。