このトピックでは、バージョン 8.1 のアプリケーションをアップグレードするときに行われる変更のリストを示します。
プロジェクト モデルの変更 (フォルダ階層、ファイル拡張子、プロジェクト タイプなどの変更)
Javadoc スタイルのアノテーションの Java 5 アノテーションへの置き換え
バージョン 10.x で更新されたバージョン 8.1 の機能
バージョン 10.x でサポートされなくなったバージョン 8.1 の機能
バージョン 8.1 からバージョン 10.x へのプロジェクト モデルの変更の多くは、広く使用されている Eclipse と Java の規約にモデルを合わせることを意図しています。他の Eclipse ベースの IDE を使用したことがあるならば、Workshop バージョン 10.x は親しみやすく感じられるはずです。
注意 : また、「WebLogic Workshop 8.1 ユーザに対する主な相違点」も参照すべき場合があります。
次のリストに、バージョン 8.1 とバージョン 10.x のプロジェクト モデルの最も大きな相違点を示します。
バージョン 8.1 で使用されていた Javadoc コメント スタイルのアノテーションからバージョン 10.x でサポートされている Java 5 アノテーションへの変更は、このアップグレードにおけるもっとも大きな特徴の 1 つです。詳細については、「アノテーションのアップグレード」を参照してください。バージョン 8.1 のアノテーションの多くは、対応するアノテーションがバージョン 10.x にあります。詳細については、「バージョン 8.1 とバージョン 10.x のアノテーション間の関係」を参照してください。
以下の機能は、バージョン 10.x では対応する代替機能に更新されており、非推奨になる可能性があります。
影響を受ける対象 : Web サービス
アップグレードすることを強くお勧めします。バージョン 8.1 では、Web サービスのメッセージレベルのセキュリティは WS-Security (WSSE) ポリシー ファイルを使用して管理されました。バージョン 10.x では、Web Services Policy Framework (WS-Policy) を使用する必要があります。
WS-Policy セキュリティ ポリシーへの手動による更新については、「WS-Security から WS-Policy へのセキュリティのアップグレード」を参照してください。
Web サービスのセキュリティ モデルが変更されたことにより、バージョン 10.x のサービス コントロールを使用したセキュリティ特性の指定方法がバージョン 8.1 とは異なっています。バージョン 8.1 では、WebLogic Workshop WSSE ポリシー ファイル内にセキュリティ ポリシーと値の両方を指定しました。バージョン 10.x では、これら 2 つのセキュリティ要素の特性を複数の場所に分けて指定するようになっています。
セキュリティ設定の新しい指定方法については、「サービス コントロールを使用した実行時のメッセージ レベル セキュリティのコンフィグレーション」を参照してください。
アプリケーションのセキュリティ関連の特性の中には、バージョン 8.1 のアプリケーションをアップグレードする過程で、Workshop に付属のドメインと再デプロイ先になるアップグレードされたドメインで動作が異なってしまうものがあります。アップグレードされたアプリケーションのデプロイ先になるアップグレードされたドメインには下位互換性があるのに対して、Workshop に付属の「新しい」10.x ドメインには下位互換性がないことが原因です。
詳細および回避策については、「web.xml 内のマップされていないエントリに関する問題の解決」を参照してください。
影響を受ける対象 : Web サービス
サポートされていますが、非推奨になっています。バージョン 8.1 では、送信 SOAP エラーの内容を制御するためのラッパー クラスと受信 SOAP エラーから内容を取得するための API が提供されていました。JAX-RPC を使用して SOAP エラーを例外にマップすることで、この機能を置き換えることができます。
詳細については、「SOAP エラーを処理するためのラッパー クラスに代わる機能」を参照してください。
影響を受ける対象 : Web サービス
サポートされていますが、非推奨になっています。バージョン 8.1 では、アプリケーションまたはランタイムからチェック済み例外が送出されると、コンテナ管理によるトランザクションはランタイムでロールバックされました。バージョン 10.x では、この動作は、アップグレード時にアップグレード ツールによって Web サービスのソース コードに追加されるアノテーションによりサポートされます。
この変更と対応策の詳細については、「自動トランザクション ロールバックに対するアップグレードでの変更」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 では、start オペレーションおよび finish オペレーションのない「会話形式の」Web サービスをコンパイルできました。つまり、Web サービス クラスに会話形式としてアノテーションを付けることができました。しかし、そのオペレーションに会話の phase 属性を付けることはできませんでした。バージョン 10.x では、会話形式の Web サービスは start オペレーションおよび finish オペレーションの両方がなければコンパイルできません。
詳細については、「会話の start メソッドおよび finish メソッドの確認」を参照してください。
影響を受ける対象 : Web サービス
バージョン 10.x でもステートフル オペレーションとステートレス オペレーションの両方を含む Web サービスはサポートされますが、このサポートは非推奨になっています。アップグレードされた会話形式の Web サービスでは、ステートレス オペレーションには非推奨のアノテーション @Conversation(value = Conversation.Phase.NONE) が付けられます。
詳細については、「ステートフル オペレーションとステートレス オペレーションが混在している Web サービスに対するアップグレードでの変更」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 とバージョン 10.x では Web サービスのデフォルトの targetNamespace 値を生成する方法が異なるため、アプリケーション内に同じクラス名の Web サービスが複数あるとデプロイメント エラーが発生する場合があります。バージョン 10.x の Web サービスに対しては、WebLogic Server では内部で使用するリソースをバインドするために Web サービスの targetNamespace 値が含まれた完全修飾されたポート名が使用されます。そのため、ポート名はアプリケーション内でユニークでなければなりません。
このエラーの解決については、「同一名の Web サービスに対するデプロイメント エラーの解決」を参照してください。
影響を受ける対象 : Web サービス
Web サービスのメソッド パラメータ名が、その Web サービスの作成時に使用した WSDL 内の対応する名前と一致していない場合、その Web サービスをアップグレードした後で各パラメータに @WebParam アノテーションを追加する必要があります。
詳細については、「オペレーション パラメータの名前と WSDL 内での名前との不一致に関するサポート」を参照してください。
影響を受ける対象 : Web サービス
Workshop のアップグレード ツールでは、信頼性のあるメッセージングのサポート (@jws:reliable アノテーションなど) はバージョン 8.1 からバージョン 10.x にアップグレードされません。 バージョン 8.1 のドキュメントに記載されているように、バージョン 8.1 の信頼性のあるメッセージング (RM) のサポートは非常に限定されたものであり、将来のバージョンでもサポートされる仕様に基づいたものではありませんでした。信頼性のあるメッセージングのサポートは手作業でアップグレードできます。
アップグレード手順の概要については、「信頼性あるメッセージングのサポートのアップグレード - 基本的な手順」を参照してください。
バージョン 9.x では、HTML フォームから送信されるメッセージの、form-get メッセージ フォーマットおよび form-post メッセージ フォーマットを使用した受信はサポートされていません。これらのフォーマットを使用する Web サービスをアップグレードする場合、Web ブラウザのフォームから送信されるデータの受信には別の方法を使用する必要があります。
つまり、バージョン 10.x の Web サービスでは SOAP ヘッダを含まないメッセージ フォーマットはサポートされていません。
バージョン 8.1 の @jws:protocol アノテーションでは、以下の属性と値がサポートされていました。
@jws:protocol form-get="true" - オペレーションまたは Web サービスで HTTP GET リクエストの受信がサポートされていることを示しました。@jws:protocol form-post="true" - オペレーションまたは Web サービスで HTTP POST リクエストの受信がサポートされていることを示しました。バージョン 10.x には、これらの属性と値に対応するものがなく、推奨される対応策もありません。バージョン 10.x にアップグレードする場合、サポートされていないプロトコル設定はアップグレード ツールで単に無視されます。
影響を受ける対象 : Web サービス
バージョン 8.1 で xs:any ではなく xs:anyType が指定された WSDL を使用して Web サービスを作成した場合、バージョン 10.x にアップグレードした後、その Web サービスは誤った XML ペイロードを送受信しようとします。
xs:anyType が正しく処理されるようにするには、該当する Web サービスのクラス レベルに @WildcardBindings アノテーションを適用する必要があります。詳細については、「メッセージ内の xs:anyType が正しく処理されるようにするための変更」を参照してください。
影響を受ける対象 : Web サービス、コントロールの使用
バージョン 8.1 ではサービス コントロールを WSDL に関連付けないようにできましたが、正常にアップグレードするためにはサービス コントロールを WSDL に関連付ける必要があります。
WSDL とサービス コントロールの関連付けの詳細については、「サービス コントロールの WSDL への関連付け」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 では抽象 WSDL (サービス定義のない WSDL) からサービス コントロールを生成できました。その後、呼び出しやリスンを行うためのエンドポイントをプログラム的にまたはアノテーションを使用してコンフィグレーションできました。しかし、WebLogic Server バージョン 10.x では抽象 WSDL はサポートされていません。そのため、Workshop のアップグレード ツールでは必要なアノテーションとともにサービス コントロールをアップグレードできず、アップグレードされたコードにコンパイル エラーが残されます。同様に、9.x で抽象 WSDL からサービス コントロールを生成しようとすると、サービスが必須であることを示すエラーが表示されます。
詳細と推奨される対応策については、「抽象 WSDL に基づいたサービス コントロールのアップグレード」を参照してください。
ServiceControl.getEndPoint() メソッドおよび ServiceControl.setEndPoint(URL) メソッドはバージョン 10.x では非推奨となっており、将来のバージョンで削除される可能性があります。新しいコードでこの種類の API が必要になる場合は、それぞれ ServiceControl.getEndpointAddress() および ServiceControl.setEndpointAddress(String) を使用する必要があります。
詳細については、「サービス コントロール メソッド getEndPoint および setEndPoint の置き換え」を参照してください。
アップグレード ツールでは、コントロール メソッド パラメータの JMS プロパティへのバインディングに対する JMS コントロール サポートは完全にはアップグレードされません。具体的に言うと、メソッド パラメータ自体にアノテーションを付ける必要がありますが、アノテーションは付けられません。バージョン 8.1 のコードのアップグレード後に必要なアノテーションを手動で追加することによって、これらのバインディングを確実にサポートできます。
詳細については、「JMS コントロールにおける JMS プロパティとパラメータとのバインディングのサポート」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 8.1 ではコントロールはエンタープライズ JavaBean のコンテキスト内で実行されるため、それらはトランザクションのスコープ内で自動的に実行されます。バージョン 10.x では、コントロールは POJO (Plain Old Java Object) になるため、コントロールにトランザクション サポート用の @TransactionAttribute アノテーションを付ける必要があります。このアノテーションは、アップグレード時に アップグレード ツールによって追加されます。
トランザクション サポートの追加については、「コントロールにおける自動トランザクションのサポートの有効化」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 8.1 のデータベース コントロールに対応している、バージョン 10.x の標準的な JdbcControl (org.apache.beehive.controls.JdbcControl) では、バージョン 8.1 の「RowSet コントロール」機能はサポートされていません。アップグレード時に行セット機能が確実に保持されるようにするため、データベース コントロールは BEA から提供されている下位互換性のある JdbcControl (com.bea.control.JdbcControl) にアップグレードされます。
詳細については、「データベース コントロールの行セット機能をサポートするための変更」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 8.1 では、コントロール イベント ハンドラは捕捉された例外または java.lang.Exception などのスーパークラスを送出することで、コントロールから捕捉された例外を送出できました (コントロール イベント ハンドラはバージョン 8.1 では「コールバック ハンドラ」と呼ばれていました)。バージョン 10.x では、捕捉された例外をイベント ハンドラが送出する場合には、コントロールの EventSet メソッドに対して宣言された適切な throws 句のサブセットを代わりに送出する必要があります。
新しい要件への対応については、「コントロール イベント ハンドラでの例外処理のアップグレード」を参照してください。
バージョン 8.1 では、カスタム コントロールのインタフェース コードまたは実装コードに common:message-buffer タグを適用できました。バージョン 10.x では、このアノテーションに対応するアノテーション com.bea.control.annotations.MessageBuffer はコントロールのインタフェース コードでしかサポートされていません。この変更に対応するには、アプリケーションをアップグレードする前に、該当するアノテーションを実装コードから削除する必要があります。
バージョン 8.1 では、Web サービス (バージョン 8.1 の JWS ファイル) やカスタム コントロールなどのコンポーネントが実行時環境と対話するためのコンテキスト API が提供されていました。Web サービスについては、JwsContext の場所が変更されたほか、一部のメソッドが使用できなくなっています。コントロールについては、バージョン 10.x でコントロール モデルが導入されたことにより、バージョン 8.1 のコントロール コンテキスト クラスによってエクスポーズされていたいくつかの API について、エクスポーズ方法が変更されたか、または必要がないため使用できなくなりました。
影響を受ける API の一覧については、「コンテキスト API の変更に対する処理」を参照してください。
影響を受ける対象 : エンティティ Bean
バージョン 8.1 では、指定されていないトランザクション内でエンティティ Bean が実行された場合、EJB コンテナによってそのエンティティ Bean に対するトランザクションが作成されました。バージョン 10.x では、デフォルトではトランザクションは作成されません。
旧バージョンのデフォルト動作のサポートについては、「エンティティ Bean における自動トランザクションのサポートの有効化」を参照してください。
影響を受ける対象 : アノテーションを使用するコード
バージョン 8.1 とは異なり、バージョン 10.x ではアノテーションは Java 型であり、コード内でインポートされるか、または完全に修飾される必要があります。これらの型を使用するコードを追加することでバージョン 8.1 のコード内のアノテーションがアップグレードされるため、8.1 のコードですでに使用されている型と同じ名前のアノテーションが追加されるとあいまいさの問題が発生する場合があります。
こうしたあいまいさを修正する方法については、「アノテーションの型に関連するあいまいさの解決」を参照してください。
影響を受ける対象 : JSP ファイル
バージョン 8.1 の NetUI タグと NetUI タグには多数の相違点があるため、JSP タグのアップグレードを選択すると JSP タグが一部変更される場合があります。詳細については、「バージョン 8.1 の NetUI JSP タグからのアップグレード時の変更点」を参照してください。
影響を受ける対象 : JSP ファイル
アップグレードされたアプリケーションでは式言語のデフォルトとして下位互換性のあるバージョンが設定されます。下位互換性のあるバージョンはバージョン 10.x よりも寛容性があり、バージョン 8.1 のコードの移行を可能にします。デフォルトの式言語の変更については、「JSP タグで使用されるデフォルトの式言語の変更」を参照してください。
影響を受ける対象 : JSP ファイル
アップグレード ツールでは、要求に応じて、NetUI JSP タグからバージョン 10.x JSP タグへの移行が実行されます。これには、NetUI 式言語構文からバージョン 10.x JSP 式言語の構文への移行も含まれます。ただし、NetUI 式の場合と同様にバージョン 10.x JSP 式言語の式でもパブリック フィールドにバインドできません。つまり、バージョン 10.x JSP タグに完全にアップグレードするには、パブリック フィールドが使用されていた場所に get* アクセサおよび set* アクセサを手動で追加する必要があります。
こうした相違点の詳細については、「 NetUI JSP タグで式言語をサポートするためのコードの変更」を参照してください。
アプリケーションのセキュリティを強化するために、org.apache.beehive.netui.pageflow.PageFlowController および org.apache.beehive.netui.pageflow.FlowController の一部のパブリック メソッドが保護されるように変更されました。この変更により、これらのメソッドは JSP ページ内から Bean プロパティとして呼び出すことができなくなりました。
詳細については、「詳細 : 一部のパブリックだった PageFlowController メソッドおよび FlowController メソッドの保護化」を参照してください。
影響を受ける対象 : XMLBeans を使用するコード (Web サービス、コントロール、JSP ファイル、エンタープライズ JavaBean など)
アップグレード時に XMLBeans API の型に対するパッケージは com.bea.xml から org.apache.xmlbeans に変更されます。さらに、バージョン 8.1 のアプリケーションにスキーマ プロジェクト (スキーマの XMLBeans 型への自動コンパイルをサポートしたプロジェクト) が含まれている場合、そのプロジェクトは引き続きスキーマが XMLBeans 型にコンパイルされるバージョン 10.x のプロジェクトに移行されます。
影響を受ける対象 : XML スキーマ
バージョン 10.x では、バージョン 8.1 で使用されていたものよりも厳密なスキーマ バリデータが使用されます。アップグレード プロセスでは、バージョン 8.1 では有効と判断されていた可能性のある無効なスキーマは修正されません。このため、有効性が重要なスキーマを処理する場合には、スキーマ検証が有効になっていることを確認してください。
影響を受ける対象 : XMLBeans および XQuery を使用するコード (Web サービス、コントロール、ページ フロー、エンタープライズ JavaBean など)
旧バージョンの XQuery 実装は非推奨になっていますが、このバージョンでは下位互換性を保持するためにサポートされています。旧バージョンの実装に基づくクエリは保持されますが、旧バージョンの実装が使用されるように指定するための特別な XmlOptions パラメータが追加されます。
例外は、JSP ファイルでの XQuery の使用です (JSP ファイルの XQuery はアップグレード ツールでアップグレードされません)。手動で変更を行う必要があります。詳細については、「アップグレードされた XQuery 実装をサポートするための XQuery の使用の更新」を参照してください。
影響を受ける対象 : ビルド プロセス
バージョン 8.1 でカスタム Ant ビルド スクリプトを作成した場合、それらをバージョン 10.x で使用するには手動でアップグレードする必要があります。 アプリケーションのアップグレード後に、Ant ビルド ファイルを再エクスポートしてからカスタマイズを結合することによってカスタマイズを移行できます。
注意 : バージョン 8.1 とは異なり、バージョン 10.x では IDE 内からの Ant を使用したアプリケーションのビルドはサポートされていません。ビルド ファイルをエクスポートして、コマンドラインからターゲットを実行する必要があります。詳細については、「Ant ビルド ファイルを使用したアプリケーションのビルド」を参照してください。
Ant ビルド ファイルをエクスポートするには、バージョン 10.x で次の手順に従います。
WebLogic Server 上で使用するプロジェクトをビルドするように設計されたスクリプトを生成するには、名前に「(WebLogic Server)」があるジェネレータを選択する必要があります。「Java プロジェクト ビルド スクリプト」は選択しないでください。これは Java ファイルをコンパイルしますが、WebLogic Server 用のプロジェクトをビルドするように設計されていません。
必要なカスタマイズをサポートするように、生成されたスクリプト ファイルを編集できます。
生成された Ant スクリプト ファイルのターゲットを実行する場合には、ワークスペースの場所を示すパラメータ値をスクリプトに渡す必要があります。これは -Dworkspace コマンドライン オプションを使用する 2 種類の方法のいずれかで行うことができます。次のように、ワークスペース メタデータ ファイルの場所を指定することもできます。
ant -buildfile build.xml -Dworkspace=c:\workspaces\MyWebServices\workspace.xml
メタデータ ファイルを生成するには、上記で説明したとおりに Ant スクリプト ファイルのメタデータ ファイルをエクスポートします。[エクスポート] ダイアログで [Workspace Metadata for Workshop Ant Scripts] を選択します。以降のダイアログで、ファイルに含めるメタデータの属するプロジェクトと、必要な特定の変数値を選択します。新しいプロジェクトの EAR への追加などワークスペースの設定を変更するたびに、メタデータ ファイルを再エクスポートする必要があります。
ワークスペース ディレクトリを引数として指定することもできます。
ant -buildfile build.xml -Dworkspace=c:\workspaces\MyWebServices
影響を受ける対象 : IDE 拡張機能
Workshop バージョン 10.x は Eclipse に基づいています。Eclipse には、Eclipse ユーザにはプラグインとして知られている、拡張機能を開発するための独自のモデルと API が用意されています。バージョン 8.1 の拡張機能はアップグレードされません。バージョン 8.1 のモデルに基づいて記述された拡張機能をバージョン 9.2 でも保持するには、拡張機能を書き換える必要があります。バージョン 8.1 のモデルに基づく拡張機能を使用していた場合は、Eclipse 拡張セットで類似する機能を見つけなくてはなりません。
Eclipse プラグインの詳細については、このドキュメントの Eclipse ヘルプ、またはオンライン ヘルプを参照してください。
影響を受ける対象 : コンフィグレーション
WebLogic Workshop バージョン 8.1 では、WebLogic Workshop で構築されたアプリケーションの実行時環境をコンフィグレーションするためのファイル群が提供されていました。これらのファイルはバージョン 10.x には含まれていません。
それらのファイルで設定されたプロパティの多くは、バージョン 9.2 では WebLogic Administration Console を使用してコンフィグレーションしたり、WebLogic Server Scripting Tool (WLST) を使用してスクリプト化したりできます。たとえば、jws-config.properties を介して設定した特定の値については、『MBean リファレンス』の「WebServiceMBean」を参照してください。
Administration Console の詳細については、「Adminstration Console の概要」を参照してください。WLST の詳細については、「WebLogic Scripting Tool ガイド」を参照してください。
Workshop のアップグレード ツールではワイルドカード インポート文はアップグレードされないため、バージョン 10.x にライブラリが存在しない一部のワイルドカード インポート文によって、バージョン 10.x でエラーが発生します。これらの文をバージョン 10.x の対応する文に置き換えることで、エラーを修正できる場合もあります。
一部のワイルドカード インポート文は、アップグレード時にバージョン 10.x の最も類似する機能を反映するように変更されます。
以下の機能は、バージョン 9.2 ではサポートされなくなりました。以下では、バージョン 8.1 ではサポートされていたが、バージョン 10.x で機能するためにはアップグレードされたコードを書き換える必要のある機能について説明します。
影響を受ける対象 : Web サービス、サービス コントロール
バージョン 10.x では XQuery マップ (Web サービスのオペレーションをやり取りする XML メッセージを XQuery を使用して再成形するためのバージョン 8.1 の機能) はサポートされていません。この変更は Web サービス自体でサポートされる XML 形式に影響を与えるだけでなく、Web サービスと、その Web サービスまたは WSDL ファイルから生成されるサービス コントロールとの不一致も引き起こします。これを回避する方法の 1 つは、マップを使用しないで、WSDL が既存の WSDL 形式に一致するようにコードを書き換えることです。
注意 : XQuery マップがサポートされなくなっても、XQuery 自体はサポートされています。引き続き XMLBeans API を使用して XQuery 式を実行できます。この API に影響を与えるアップグレードでの変更については、「アップグレードされた XQuery 実装をサポートするための XQuery の使用の更新」を参照してください。
詳細については、「XQuery マップを置き換えるための一般的な手順」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 では、Web サービスのオペレーションから java.util.Map のインスタンスを返すことがサポートされていました。XML とのマップの、WebLogic Workshop 固有のシリアライゼーションがランタイムで提供されていました。そのシリアライゼーションのスキーマは、Web サービスの WSDL に含まれていました。バージョン 10.x では、java.util.Map インスタンスを Web サービスのオペレーションから返すことができなくなっています。
推奨される対応策については、「Web サービス オペレーションの戻り値の型としての java.util.Map の使用の置き換え」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 とは異なり、バージョン 10.x では Web サービスで定義されるバインディングでの複数の SOAP バージョンの使用はサポートされていません。アップグレードする場合は、複数の SOAP バージョンを使用しているすべての Web サービスを、1 つの SOAP バージョンのみを使用するように手動で編集する必要があります。
影響を受ける対象 : Web サービス
バージョン 8.1 には、SOAP 1.2 仕様の草案に基づく SOAP 1.2 実装が含まれていました。バージョン 10.x の SOAP 1.2 実装は、この仕様の最終バージョンに基づいているため、旧バージョンの実装とは異なっています。バージョン 8.1 で作成された、SOAP 1.2 の Web サービスのクライアントとの互換性を確保するには、アップグレードされたバージョン (バージョン 10.x) の Web サービスから生成された WSDL を使用してクライアントを再ビルドする必要があります。
WSDL の生成の詳細については、「バージョン 8.1 の SOAP 1.2 実装からのアップグレード」を参照してください。
影響を受ける対象 : Web サービス
HTTP または JMS を介する非 SOAP の XML フォーマットを使用するバージョン 8.1 の Web サービスがある場合は、SOAP プロトコルまたはそれに代わるプロトコルを使用するように Web サービスをバージョン 10.x 上で変更する必要があります。
Web サービスのメッセージ フォーマットの変更については、「詳細 : HTTP または JMS を介する非 SOAP の XML メッセージ フォーマットの非サポート」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 では、@jc:handler および @jws:handler アノテーションに callback 属性があり、コールバックに関連付けられた SOAP メッセージを処理するハンドラを指定するために使われていました。バージョン 10.x には、コールバックに特有のハンドラ サポート機能はありません。バージョン 10.x でこれらのアノテーションに対応する機能については、「アノテーションのアップグレード」を参照してください。
影響を受ける対象 : Web サービス
バージョン 10.x では、HTML フォームから送信されるメッセージの、form-get メッセージ フォーマットおよび form-post メッセージ フォーマットを使用した受信はサポートされていません。これらのフォーマットを使用する Web サービスをアップグレードする場合、Web ブラウザのフォームから送信されるデータの受信には別の方法を使用する必要があります。
詳細については、「詳細 : データ受信での form-get メッセージ フォーマットおよび form-post メッセージ フォーマットの非サポート」を参照してください。
影響を受ける対象 : Web サービス
バージョン 10.x では、Web サービス レベルでの複数プロトコルの使用はサポートされていますが、バージョン 8.1 で提供されていたオペレーション レベルでの複数プロトコルの使用はサポートされていません。アップグレード時に 1 つの Web サービス内のオペレーションで異なるプロトコルが使用されている場合は、別々の Web サービスを作成してサービスごとに 1 つのプロトコルが使用されるようにサービス間でオペレーションを分割する必要があります。
この変更については、「Web サービス内の複数のプロトコルに対するアップグレードでの変更」を参照してください。
影響を受ける対象 : Web サービス
バージョン 8.1 の Web サービスに、RPC SOAP バインディングを使用する 1 つ以上のオペレーションと、ドキュメント SOAP バインディングを使用する 1 つ以上のオペレーションが両方とも含まれている場合、アップグレード後には、それらのオペレーションに対して生成される型が異なるネームスペースに配置されます。アップグレードされた Web サービスはバージョン 8.1 の Web サービス自体とは異なったものになります (バージョン 8.1 の Web サービスでは型は同じネームスペースにありました)。アップグレードされた Web サービスから生成される WSDL も、バージョン 8.1 の Web サービスから生成される WSDL とは異なります。
対応策を含む詳細については、「ドキュメント SOAP バインディングを使用するオペレーションと RPC SOAP バインディングを使用するオペレーションの混在によって生じるネームスペース相違の解決」を参照してください。
サポートされていますが、非推奨になっています。アップグレードされた Web サービスおよびサービス コントロールのコードには、クラス レベルで適用される @UseWLW81BindingTypes アノテーションおよび @WLWRollbackOnCheckedException アノテーションが含まれます。これらのアノテーションは非推奨になっていますが、バージョン 8.1 のコードを使用するクライアントをサポートするために必要です。
影響を受ける対象 : Web サービス
バージョン 8.1 では、WSDL で複数のサービスが定義されている Web サービス (JWS) またはサービス コントロールを含めることができました。Web サービスまたはコントロールは、これらのサービスのいずれか 1 つのみを表しました。このようなコードをバージョン 10.x にアップグレードすると、アップグレードが失敗します。このようなコードのアップグレードを確実に成功させるには、JWS またはサービス コントロールによって表されるサービスのみを定義するようにするように WSDL を編集する必要があります。
バージョン 8.1 のサービス コントロールに関連付けられる WSDL に対しては <wsdl:import> 要素の複数回の出現がサポートされていましたが、バージョン 10.x ではこの要素の複数回の出現は同一の WSDL 内ではサポートされていません。従来は、たとえば 1 つのインポート文で WSDL の WSDL 部分を取得し、もう 1 つのインポート文で必要な型の XSD 部分を取得するといった記述ができました。
詳細および考えられる対応策については、「複数の <wsdl:import> 文が含まれる WSDL のアップグレード」を参照してください。
バージョン 8.1 では、1999 スキーマ ネームスペースに属する型を WSDL で使用し、生成されたサービス コントロールおよび Web サービスでそれらの型を使用することがサポートされていました。バージョン 10.x ではこのネームスペースの型はサポートされていないため、WSDL を 2001 ネームスペースに手動で移行する必要があります。
詳細については、「1999 ネームスペースから 2001 ネームスペースへの WSDL の更新」を参照してください。
EJB コントロールは他のタイプのコントロールとは仕組みが異なっているために、アップグレード ツールでは EJB コントロールで使用されるセキュリティ アノテーションを自動的にアップグレードできません。この相違に対処するには、必要なメソッドとアノテーションを含むように EJB コントロール拡張ファイルを手動で編集する必要があります。
詳細および例については、「EJB コントロールにおけるセキュリティのアップグレード」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 8.1 の EJB コントロールからエクスポーズされる getJNDIName メソッドおよび setJNDIName メソッドについてはバージョン間の相違があるため、アップグレードされたコードでエラーが発生します。バージョン 8.1 ではこれらのメソッドは EJBControl.getJNDIName および EJBControl.setJNDIName としてエクスポーズされましたが、バージョン 10.x ではビルド時に生成されるコントロール Bean クラスから getJndiName および setJndiName としてエクスポーズされます (大文字小文字の違いにも注意)。
メソッド呼び出しコードの修正については、「EJB コントロールの getJNDIName および setJNDIName に対するメソッド呼び出しのアップグレード」を参照してください。
バージョン 8.1 のデータベース コントロールでは、@jc:sql array-max-length 属性の値として「all」を指定することでクエリに対するすべての行の取得がサポートされていました。バージョン 10.x の JDBC コントロールでは、この値はサポートされていません。代わりに数値を指定します。アップグレード ツールでは、この変更は自動的には行われません。
詳細については、「データベース コントロールの結果に対する「all」リクエストの置き換え」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 10.x では、コントロール ファクトリ (実行時に 1 つのコントロールから複数のコントロール インスタンスを作成できるバージョン 8.1 の機能) はサポートされていません。コードでコントロール ファクトリが使用されている場合は、その機能を代替のソリューションに置き換える必要があります。
推奨される代替のソリューションについては、「コントロール ファクトリ機能の置き換え」を参照してください。
影響を受ける対象 : JMS コントロール
バージョン 10.x では JMS コントロールを使用してメッセージを受信できません。アップグレードされたコードでこの問題に対応するには、メッセージを受信するためのメッセージ駆動型 Bean (MDB) を開発するか、または非同期のリクエストと応答を使用する Web サービスを呼び出します。
バージョン 8.1 の JMS コントロールは sendJMSMessage メソッドのパラメータとして JMSControl.Message 型を取りましたが、バージョン 10.x ではこのメソッドは javax.jms.Message のインスタンスを取ります。完全にアップグレードするには、それに従ってコードを変更する必要があります。
詳細については、「JMS コントロールの sendJMSMessage に対するメソッド呼び出しのアップグレード」を参照してください。
影響を受ける対象 : コントロールの使用
バージョン 8.1 ではタイマー コントロールの start メソッドを複数回呼び出してもエラーなしでタイマーを開始することができましたが、onTimeout コールバックは start メソッドの個々の呼び出しに必ずしも対応していませんでした。バージョン 10.x のタイマー コントロールでは、start メソッドの複数回呼び出しを許可しないことで API が簡素化されています。タイマー コントロールがまだ実行中である場合に start メソッドを呼び出しても効果はありません。
影響を受ける対象 : コントロールの使用、ページ フロー
バージョン 10.x では、ページ フロー内のカスタム コントロールで外部コールバックを受信できません。バージョン 8.1 では、カスタム コントロール内にネストされているコントロール (サービス コントロールなど) からのコールバックを、そのカスタム コントロールで受信するコードを記述できました。カスタム コントロールからポーリング インタフェースをエクスポーズすることで、ページ フロー コードでコールバックから受信した応答を取得できました。この機能はバージョン 10.x ではサポートされていません。
アップグレードされたコード内でカスタム コントロールを Web サービスに置き換えることで、この機能の代わりとすることができます。バージョン 8.1 の該当する機能と、バージョン 10.x において考えられる回避策の詳細については、「ページ フローでコントロール コールバックをサポートする方法」を参照してください。
影響を受ける対象 : Web サービス、コントロールの作成
これらは、使用頻度が低いと見なされたか、またはコントロールのランタイムに含めるほど一般的ではなかったイベントおよび API です。
ロギング API などを使用している状況では、apache.commons のロギング API など、スタンドアロンの API や WebLogic Server で提供される API を直接使用するようにアプリケーションを変更できます。ただし現時点では、API が実行時コンテナに密接に関連付けられている状況における対応策はありません。
影響を受ける対象 : コントロールの作成
バージョン 8.1 のカスタム コントロールのアノテーション定義は、バージョン 10.x にアップグレードされません。バージョン 10.x ではアノテーションを定義するための方法は Java 5 アノテーション モデルに基づきます。バージョン 8.1 向けに記述されたコントロールをアップグレードするには、アノテーション定義を新しいモデルに合わせて書き換える必要があります。
詳細については、「カスタム プロパティを使用するカスタム コントロールのアップグレード」を参照してください。
影響を受ける対象 : ページ フロー
バージョン 8.1 では、コントローラ ファイル (Controller.jpf) と JSP ファイルを同じディレクトリに配置できるプロジェクト階層がサポートされていました。これはバージョン 10.x ではサポートされていません。 アップグレード時には、コントローラ ファイルが JSP ファイルと共存しないようにプロジェクト階層が変更されます。
詳細については、「ページ フローでの共存に対するアップグレードでの変更」を参照してください。
バージョン 8.1 の IDE には、IDE で関連ファイルを同期した状態で保持するための一連の機能が含まれていました。たとえば、WSDL からサービス コントロールが生成された後に WSDL に対して変更が行われると、それに対応するように IDE でサービス コントロールが自動的に再生成されました。この機能はバージョン 10.x の IDE ではサポートされていません。
推奨される対応策については、「IDE のサポートがない場合のファイルの同期」を参照してください。
バージョン 8.1 で NetUI タグを拡張してカスタム JSP タグを作成した場合、それらのタグは Workshop ツールではアップグレードされません。NetUI タグの拡張はサポートされていませんでした。NetUI タグを現在のタグに移行しないことを選択した場合には、それらのタグはアプリケーション内でビルドされますが、想定どおりに機能しないおそれがあります。
同様に、バージョン 10.x での JSP タグの拡張もサポートされていません。
バージョン 9.2 の IDE では、HTML 開始タグ内で変数宣言が行われるコードに対してエラーが誤って表示されます。実際には実行時にコードは有効です。たとえば、次の参照先にあるアンカー タグでは String 変数を使用している <%=s%> コードが IDE によって未解決として示されますが、実際には有効です。