WebLogic のアプリケーション環境のアップグレード
|
 |
 |
|
この節では、WebLogic Server 9.0 にアップグレードする前に考慮するべき重要な互換性に関する情報について説明します。
注意 : 『BEA WebLogic Server 9.0 の互換性について』(http://edocs.beasys.co.jp/e-docs/wls/docs90/compatibility/compatibility.html) も参照してください。
WebLogic Server 9.0 では、JDK 5.0 に含まれている Java Management Extensions (JMX) 1.2 実装が使用されています。9.0 より前のリリースでは、JMX 1.0 仕様をベースにした独自の JMX 実装が使用されていました。
JMX 1.2 参照実装の採用により、シリアライゼーションの互換性がなくなりました。参照実装においてシリアライゼーションの互換性はなくなりましたが、WebLogic Server 8.1 用に作成された JMX クライアントは、次のように 9.0 でも使用することができます。
weblogic.management.MBeanHome のみを使用する場合は、アップグレードしなくても WebLogic Server 9.0 インスタンスで実行することができる weblogic.management.MBeanHome のみを使用する (JDK MBeanServer インタフェースを使用しない)-Djmx.serial.form=1.0 を含める必要があるこの起動オプションを含めると、JVM がオブジェクトをシリアライズするときに JMX 1.0 のクラス記述が使用されるようになります。このオプションは、JMX 1.0 クライアントが標準の JDK クラスを使用して JMX 1.2 エージェントと通信する場合に必要です。
JMX クライアントを WebLogic Server 9.0 に準拠するよう更新することをお勧めします。9.0 より前では、WebLogic Server は JMX レイヤに対して、型付き API レイヤをサポートしていました。使用する JMX アプリケーション クラスでは、WebLogic Server MBean の型保障インタフェースをインポートしたり、weblogic.management.MBeanHome インタフェースを介して MBean の参照を取得したり、MBean メソッドを直接呼び出すことができました。
MBeanHome インタフェースは、9.0 から非推奨となりました。この API のようなプログラミング モデルを使用する代わりに、すべての JMX アプリケーションで、標準の JMX プログラミング モデルを使用してください。標準の JMX 設計パターンでは、クライアントは javax.management.MBeanServerConnection インタフェースを使用して、実行時に MBean、属性、および属性タイプを検索します。この JMX モデルでは、クライアントは MBeanServerConnection インタフェースを介して間接的に MBean と対話します。
型保障インタフェース (weblogic.management から使用可能) をインポートするクラスがある場合は、そのクラスを標準の JMX プログラミング モデルを使用するよう更新することをお勧めします。詳細については、『Developing Custom Management Utilities with JMX』の「Understanding WebLogic Server MBeans」(http://edocs.beasys.co.jp/e-docs/wls/docs90/jmx/understandWLS.html) を参照してください。
コンフィグレーション属性には、「動的なもの」と「動的でないもの」があります。.
WebLogic Server 9.0 で初めて導入された変更管理プロセスにより、コンフィグレーションの変更をドメイン全体にわたってセキュアで確実に適用することができます。 バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、コンフィグレーションされているサーバまたはシステム リソースが動的でない変更の影響を受ける場合、サーバまたはシステム リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更 (動的な変更も含む) は有効になりません。この場合、システムの整合性を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお勧めします。
変更が動的でなく、再起動が必要であるかどうかを判断するには、次の手順に従います。
http://edocs.beasys.co.jp/e-docs/wls/docs90/intro/console.html) の説明に従って、Administration Console のチェンジ センタに掲載されている変更リストを表示する。isRestartRequired または showChanges のどちらかの WLST コマンド を使用する。詳細については、『WebLogic Scripting Tool ガイド』の「WLST コマンドおよび変数リファレンス」(http://edocs.beasys.co.jp/e-docs/wls/docs90/config_scripting/reference.html) を参照してください。どのセキュリティ属性が動的であるか動的でないかを確認するには、『Securing WebLogic Server』の「Security Configuration MBeans」(http://edocs.beasys.co.jp/e-docs/wls/docs90/secmanage/mbeans.html) を参照してください。
詳細については、『ドメインのコンフィグレーションについて』の「コンフィグレーションの変更の管理」(http://edocs.beasys.co.jp/e-docs/wls/docs90/domain_config/changes.html) を参照してください。
WebLogic Server 9.0 では、JDBC のコンフィグレーションを簡素化し、コンフィグレーション エラーが発生する可能性を低くするため、使用される JDBC リソースのタイプが少なくなっています。JDBC 接続プールをコンフィグレーションしてから、その接続プールを指し、JNDI ツリーにバインドされるデータ ソースまたは tx データ ソースをコンフィグレーションする代わりに、接続プールを包含するデータ ソースをコンフィグレーションできるようになりました。簡素化された JDBC リソースのコンフィグレーションの詳細については、『Configuring and Managing WebLogic JDBC』 の「Simplified JDBC Resource Configuration」(http://edocs.beasys.co.jp/e-docs/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config) を参照してください。
以下の節で説明するように、WebLogic アップグレード ウィザードは、JDBC データ ソース、接続プール、マルチプール、およびデータ ソース ファクトリを WebLogic Server 9.0 仕様に自動的に変換します。
注意 : アップグレードしたそれぞれの JDBC モジュールに内部プロパティ セクションがあります。WebLogic Server では、下位互換性に対応するため、データ ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBC データ ソース ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。
非推奨となった JDBC 機能、メソッド、インタフェース、および MBean については、『リリース ノート』の「非推奨になった JDBC の機能、メソッド、インタフェース、および MBean」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_jdbc_features) を参照してください。
アップグレード ウィザードは、従来の JDBC データ ソース/接続プールの組み合わせを 2 つのデータ ソース システム リソース モジュールに変換します (1 つはデータ ソース用、もう 1 つは接続プール用)。
注意 : ドメインのアップグレードの 1 つのプロセスとして変換されるデータ ソースのみが、その接続プールを定義するもう 1 つのデータ ソースを参照することができます。それ以外のデータ ソースは、それぞれ独自のデータベース接続プールを保有しています。
アップグレード中、アップグレード ウィザードは、データ ソースの GlobalTransactionsProtocol パラメータを、次の表に示すように、変換するデータ ソースのタイプ (tx かどうか) と対応する接続プールで使用されるドライバのタイプに応じて設定します。
EmulateTwoPhaseCommit トランザクション プロトコルではなく LoggingLastResource (LLR) トランザクション プロトコルを使用したほうが、パフォーマンス上のメリットがあります。詳細については、『Configuring and Managing WebLogic JDBC』の「Understanding the Logging Last Resource Transaction Option」 http://edocs.beasys.co.jp/e-docs/wls/docs90/jdbc_admin/jdbc_datasources.html#llr) を参照してください。アップグレード ウィザードは、マルチプールを、データ ソース間のロード バランシングとフェイルオーバーを実現するデータ ソース オブジェクトのもう 1 つのインスタンスであるマルチ データ ソースに変換します。
データ ソース ファクトリは、このリリースでは非推奨となっており、下位互換性の維持だけを目的として含まれています。データ ソース ファクトリの変換は不要です。
WebLogic Server 9.0 では、JMS コンフィグレーションはモジュールとして格納されます。これは、新しい weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントで定義されます。JMS リソースのモジュール式デプロイメントにより、アプリケーションと JMS コンフィグレーションを別の環境に移行することができます。たとえば、アプリケーションと必要な JMS コンフィグレーションを、ERA ファイルを開くことなく、またJMS を手動で再コンフィグレーションすることなく、テスト環境からプロダクション環境に移行することができます。
http://edocs.beasys.co.jp/e-docs/wls/docs90/jms_admin/intro.html#WhatsNewJMS)http://edocs.beasys.co.jp/e-docs/wls/docs90/jms_admin/overview.html)http://edocs.beasys.co.jp/e-docs/wls/docs90/deployment/deploy.html#deploy_resources)WebLogic アップグレード ウィザードは、9.0 より前のバージョンの JMS リソースを、ドメインの config\jms ディレクトリにコピーされる interop-jms.xml という名前の JMS Interop モジュール ファイルに自動的に変換します。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS Interop モジュール」(http://edocs.beasys.co.jp/e-docs/wls/docs90/jms_admin/overview.html#jms_interop_modules) を参照してください。
JMS コンフィグレーションは以下のように変更されています。
永続ダウングレードを許可] オプションにより、永続ストアがコンフィグレーションされていない JMS サーバで対象指定されている送り先に対して、永続メッセージを送信する場合に、JMS クライアントが例外を取得するかどうかを指定することができる。このオプションは、旧リリースとの下位互換性のために用意されている。 デフォルトでは、このオプションは false に設定されており、この場合、ストアがコンフィグレーションされていない JMS サーバに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションを true に設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、[ストアを有効化] パラメータが無効化されている場合 (つまり、false に設定されている場合) にのみ有効です。
詳細については、『WebLogic Server MBean リファレンス』に記載されている「JMSServerBean」の「AllowsPersistentDowngrade」(http://edocs.beasys.co.jp/e-docs/wls/docs90/wlsmbeanref/mbeans/JMSServerMBean.html#AllowsPersistentDowngrade) を参照してください。
一時的なテンプレート] 属性が作成される。旧リリースでは、デフォルトのテンプレートは提供されていなかった。JMS サーバの [一時的なテンプレート] 属性を使用して一時的なテンプレートをコンフィグレーションすることもできる。[一時的な送り先をホスト] 属性を設定して、一時的な送り先をホストするのに JMS サーバを使用できるかどうかを指定することができます。旧リリースでは、一時的な送り先をホストするのに JMS サーバを使用するには、[一時的なテンプレート] を設定する必要がありました。
http://edocs.beasys.co.jp/e-docs/wls/docs90/jms_admin/advance_config.html#jms_distributed_destination_create) を参照。AllowCloseInOnMessage 属性は、デフォルトで有効化されている。詳細については、『WebLogic Server MBean リファレンス』の「ClientParamsBean」(http://edocs.beasys.co.jp/e-docs/wls/docs90/wlsmbeanref/mbeans/ClientParamsBean.html) を参照。DeliveryFailureParamsBean の getExpirationLoggingPolicy 属性は非推奨となった。『WebLogic JMS のコンフィグレーションと管理』の「メッセージ ライフ サイクルのロギング」(http://edocs.beasys.co.jp/e-docs/wls/docs90/jms_admin/troubleshoot.html#message_life_cycle_logging) の説明に従って、メッセージのライフサイクル情報をロギングする機能を使用するようアプリケーションを更新することを勧める。getExpirationLoggingPolicy 属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要がある。
WebLogic Server 9.0 では、JMS メッセージ ID の形式が変更されています。既存のコンシューマ、プロデューサ、およびサーバで使用されている 9.0 より前のバージョンの形式は、引き続きサポートされます。たとえば、既存の JMS コンシューマは、新しい JMS プロデューサまたは JMS サーバから送信されたメッセージであっても、引き続き 9.0 より前のバージョンの形式で確認することができます。
WebLogic メッセージング ブリッジは、WebLogic Server 9.0 に完全に準拠しています。JMS メッセージング ブリッジの詳細については、『WebLogic メッセージング ブリッジのコンフィグレーションと管理』(http://edocs.beasys.co.jp/e-docs/wls/docs90/bridge/index.html) を参照してください。
スレッドを管理するようワーク マネージャをコンフィグレーションすることをお勧めします。これは、WebLogic Server 8.1 のメカニズムが WebLogic Server 9.0 では非推奨となっているためです。デフォルトでは、共通のスレッド プールが使用されます。これにより、サーバ インスタンスでスレッド プールのサイズが自動調整されてスループットが最大化されます。詳細については、『WebLogic メッセージング ブリッジのコンフィグレーションと管理』の「スレッド プール サイズの変更」(http://edocs.beasys.co.jp/e-docs/wls/docs90/bridge/tuning.html#thread_pool) を参照してください。
ドメイン レベルの JTA コンフィグレーション オプションはすべて従来のコンフィグレーション ファイルから保持されています。サーバ レベルでのみ変更があります。WebLogic Server 9.0 では、トランザクション マネージャは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ レコードを保存します。アップグレード中、アップグレード ウィザードは、トランザクション ログ レコードをデフォルト ストアにコピーします。既存のサーバ コンフィグレーションに基づいて設定されるトランザクション ログ ファイルのプレフィックスは、アップグレード中にトランザクション ログ ファイル (.tlog) を検索する目的にのみ使用され、アップグレード後は保持されません。
ドメイン全体が 1 つのマシンにある場合、アップグレード ウィザードは、初期ドメイン アップグレードにおいて、すべての管理対象サーバのアップグレードを処理します (トランザクション ログ レコードをデフォルト ストアにコピーします)。管理対象サーバが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバを個別にアップグレードする必要があります。
トランザクション回復サービスの移行の準備においてトランザクション ログ ファイルをネットワーク ストレージに配置した場合、アップグレード後、 ログ ファイルの場所は保持されません。WebLogic Server 9.0 では、WebLogic Server トランザクション マネージャは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ ファイルを保存します。デフォルトの WebLogic 永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DAT ファイルを現在のデフォルト ストアのデフォルトの場所からデフォルト ストアの新しい場所に手動でコピーする必要があることに注意してください。
トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする必要があります。詳細については、『WebLogic JTA プログラマーズ ガイド』の「ドメイン間トランザクションに対するドメインのコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/wls/docs90/jta/trxcon.html#interop) を参照してください。
以下の節では、WebLogic Server 9.0 におけるセキュリティ機能の変更について説明します。
次の表に、WebLogic Server 9.0 におけるセキュリティ MBean の変更を示します。
|
|
|
|
|
|
|
権限のないアクセスからパスワードなどの重要なデータを保護するために、コンフィグレーション MBean のいくつかの属性は暗号化されます。属性の値は、ドメインのコンフィグレーション ファイルに暗号化された文字列として保持されます。メモリ内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリから盗用されるリスクが軽減され、セキュリティがさらに強化されます。
9.0 より前のリリースでは、クリア テキスト形式または暗号化形式で、パスワードなどの暗号化する属性を config.xml ファイルで指定することができました。この場合、WebLogic Server は、次に起動され、そのファイルに書き込むときに情報を暗号化します。
WebLogic Server 9.0 では、プロダクション モードのときは、パスワードなどの暗号化する属性はコンフィグレーション ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア テキスト形式または暗号化形式のどちらでもかまいません。
次のように、weblogic.security.Encrypt コマンドライン ユーティリティを使用してパスワードを暗号化することができます。
java weblogic.security.Encrypt
ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。
このユーティリティの対象は、コンフィグレーション ファイルのパスワードだけではありません。これは、記述子ファイル (JDBC または JMS 記述子など) およびデプロイメント プランでパスワードを暗号化するのにも使用できます。詳細については、『WebLogic Server Command Reference』の「Using the WebLogic Server Java Utilities」に記載されている「encrypt」(http://edocs.beasys.co.jp/e-docs/wls/docs90/admin_ref/utils.html) を参照してください。
デフォルトでは、WebLogic Server 9.0 のインスタンスが HTTP リクエストに応答するとき、HTTP 応答ヘッダには、WebLogic Server のサーバ名およびバージョン番号は含まれません。この動作は、旧リリースの WebLogic Server とは異なります。
HTTP リクエストに応答するときにサーバ名とバージョン番号を HTTP 応答ヘッダに含めるには、Administration Console で WebLogic Server の [Send Server Header を有効化] 属性を有効にします。この属性は、[サーバ｜ServerName｜プロトコル｜HTTP] タブの [詳細オプション] セクションにあります。
セキュリティの確保の詳細については、『プロダクション環境のセキュリティ』の「プロダクション環境のセキュリティの確保」に記載されている「WebLogic セキュリティ サービスのセキュリティ」(http://edocs.beasys.co.jp/e-docs/wls/docs90/lockdown/practices.html) を参照してください。
9.0 より前のリリースの WebLogic Server では、MBeanHome への匿名アクセスがデフォルトで可能でした。9.0 では、セキュリティが強化されているため、MBeanHome への匿名アクセスはできなくなりました。
これは推奨されませんが、サーバを起動するときに次のフラグを指定することにより、匿名アクセスを再び有効にすることができます。
-Dweblogic.management.anonymousAdminLookupEnabled
WebLogic Server 8.1 Web サービスは 9.0 で実行できますが、8.1 Web サービスの実行時エンジンは 9.0 では非推奨となっています。
WebLogic Server 6.1 または 7.0 Web サービスは、9.0 で実行するには、8.1 にアップグレードする必要があります。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「WebLogic Web サービスのアップグレード」(http://edocs.beasys.co.jp/e-docs/wls/docs81/webserv/migrate.html) を参照してください。
8.1 にアップグレードされた 6.1 および 7.0 Web サービスを含む、すべての 8.1 Web サービスを 9.0 にアップグレードすることをお勧めします。既存の 8.1 Web サービスのアップグレードについては、『Programming Web Services for WebLogic Server』の「Upgrading an 8.1 Web Service to 9.0」(http://edocs.beasys.co.jp/e-docs/wls/docs90/webserv/upgrade.html) を参照してください。
以下の節では、WebLogic Server 9.0 における Web アプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。
WebLogic Server 9.0 では、JSP 2.0 が実装されています。詳細については、『リリース ノート』の「WebLogic Server 9.0 の新機能」に記載されている「Web アプリケーション、JSP、およびサーブレット」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html) を参照してください。
IllegalStateException が送出される。PageContext.getAttribute(name, PageContext.SESSION_SCOPE)
JspWriterImpl が printline 関数ごとに \n を System.getProperty("line.separator") に置き換えるようになった。この置換により、以下に該当する JSP で問題が発生する。<%@ page import="com.foo.bar.*" %>
<%@ page import="com.foo.xyz.*" %>
...
\r\n が出力される。<%@ page import="com.foo.bar.*, com.foo.baz.*"
contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %>
<param name> タグで実行時の式の値を使用できなくなった。次に例を示す。 <jsp:param name="<%= AdminActions.RETURN_LINK %>" value="<%= returnlink %>" />
「アップグレード オプションの選択」で説明されているように、ドメインのアップグレード中に [下位互換性フラグを設定しない] アップグレード オプションを無効にするか、次のように weblogic.xml ファイルで backwardCompatible フラグを有効にすることで、引き続きこの機能をサポートすることができます。
<jsp-descriptor>
<jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
WebLogic Server 9.0 で非推奨となった、またはサポートされていない Web アプリケーション機能については、『リリース ノート』の「非推奨のおよび廃止された Web アプリケーションの機能」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_and_obsolete_web_application_features) を参照してください。
WebLogic Server 9.0 では、XML のサポートは以下のように変更されています。
weblogic.apache.xerces.*) は、9.0 では非推奨となっている。デフォルトで使用される XML パーサを Administration Console で修正することができます。XML パーサのコンフィグレーションについては、『Programming WebLogic XML』の「Difference In Default Parsers Between Versions 8.1 and 9.0 of WebLogic Server」(http://edocs.beasys.co.jp/e-docs/wls/docs90/xml/overview.html#deprecated_xerces) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs90/xml/stax.html) を参照。 setAttribute メソッドと getAttribute メソッドを使用してサーブレット内から XML ドキュメントを解析することができなくなった。具体的には、9.0 では、weblogic.servlet.XMLParsingHelper と呼ばれる WebLogic Server のサーブレット フィルタ (デフォルトではすべての WebLogic Server インスタンスにデプロイされる) を Web アプリケーションの一部としてコンフィグレーションする必要がある。詳細については、『Programming WebLogic XML』の「Parsing XML Documents in a Servlet」(http://edocs.beasys.co.jp/e-docs/wls/docs90/xml/programming.html#apps005) を参照。
WebLogic Server 9.0 の XMLBean 実装は、内部 BEA ライブラリ (com.bea.xml) から Apache オープン ソース プロジェクト (org.apache.xmlbeans) に移動されています。
WebLogic Server 8.1 のアプリケーションで XMLBeans を使用していた場合は、次の手順を実行する必要があります。
WebLogic Server 9.0 の XMLQuery (XQuery) 実装は、以下の仕様に準拠します。
http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723)http://www.w3.org/TR/2004/WD-xquery-20040723)WebLogic Server 8.1 では、XQuery 実装は「XQuery 1.0 and XPath 2.0 Functions and Operators—W3C Working Draft 16 August 2002」(http://www.w3.org/TR/2002/WD-xquery-operators-20020816) に準拠していました。
ほとんどの場合、9.0 より前のバージョンのコードに含まれる簡単な XQuery および XPath は、9.0 で変更することなく使用することができます。ただし、9.0 より前のバージョンのスクリプトにおいて、コードの構文またはセマンティクスに基づいて、必要な変更がないかどうかを確認する必要があります。たとえば、場合によっては、XMLObject.selectPath() メソッドと XMLObject.execQuery() メソッドに渡される XQuery 文字列を更新する必要があります。
注意 : 9.0 では、XMLCursor.moveXML() の動作が変更されています。8.1 では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0 では、カーソルは、フラグメントと共に移動します。
MBean 階層に加えられた変更により、既存のコンフィグレーションおよび管理スクリプト (WLST、wlconfig、weblogic.Admin、Ant など) が 9.0 で実行されるかどうかは保証されなくなりました。したがって、スクリプトを更新して、WebLogic Server 9.0 の新機能を活用することをお勧めします。MBean 階層の新機能と変更点の詳細については、『リリース ノート』の「WebLogic Server 9.0 の新機能」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html) を参照してください。
アプリケーション インフラストラクチャのアップグレードと非推奨となったスクリプト ツールの詳細については、「手順 1 : アプリケーション インフラストラクチャのアップグレード」を参照してください。
WebLogic Server 9.0 で非推奨となった、またはサポートされなくなったアプリケーション デプロイメント機能については、『リリース ノート』の「非推奨のサポートされないデプロイメント機能」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_and_unsupported_deployment_features) を参照してください。
この節では、リリース 9.0 より変更された WebLogic Server 環境におけるデプロイメント記述子の使用方法について説明します。
@ejbgen:relation で cmr-field が定義されている場合に、@ejbgen:cmr-field というタグの付いたメソッドが Bean クラスになければ、エラーが返されます。注意 : ejbc は WebLogic Server 9.0 では非推奨となっていますので、代わりに appc を使用してください。詳細については、『Programming WebLogic Enterprise JavaBeans』の「appc Reference」(http://edocs.beasys.co.jp/e-docs/wls/docs90/ejb/appc_ejbc.html) を参照してください。
META-INF\application.xml デプロイメント記述子がアプリケーションの一部として定義されているかどうかに関係なく、正常にデプロイされます。<Application Deployed="true" Name="SessionBeanLifeCycleBean"</Application>
Path="C:\bea\weblogic70\tools\deployment\ejb" TwoPhase="false">
<EJBComponent Name="CMFinderTestBean" Targets="myserver" URI="CMFinderTestBean.jar"/>
<EJBComponent Name="SessionBeanLifeCycleBean" Targets="myserver"
URI="SessionBeanLifeCycleBean.jar"/>
9.0 では、デプロイされたアプリケーションが複数のモジュールを定義する場合は、META-INF\application.xml デプロイメント記述子が必要です。このタイプのデプロイメント記述子が提供されなければ、アップグレードは正常に実行されず、次のようなエラー メッセージが表示されます。
[J2EE Deployment SPI:260089]Unable to determine type of application at path 'C:\bea\weblogic70\tools\deployment\ejb' and upgrade will not succeed.
ドメインをアップグレードするとき、デプロイされたアプリケーションが適切な J2EE アプリケーション形式に準拠していることを確認してください。たとえば、必要に応じて、アプリケーションが META-INF\application.xml デプロイメント記述子と META-INF\weblogic-application.xml デプロイメント記述子の両方またはどちらかを定義していることを確認してください。
デプロイメント記述子の詳細については、『Developing Applications with WebLogic Server』の「Enterprise Application Deployment Descriptor Elements」(http://edocs.beasys.co.jp/e-docs/wls/docs90/programming/app_xml.html) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs90/programming/overview.html#ddconverter) を参照してください。
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server 9.0 では非推奨となっており、代わりにアプリケーションはアプリケーション ライフサイクル イベントに応答するようになりました。ドメイン レベルのアプリケーション スコープの起動クラスと停止クラスの代わりに新しい 9.0 のライフサイクル イベントを使用するようアプリケーション環境を更新することをお勧めします。詳細については、『Developing Applications with WebLogic Server』の「Programming Application Lifecycle Events」(http://edocs.beasys.co.jp/e-docs/wls/docs90/programming/lifecycle.html) を参照してください。
WebLogic Server 9.0 では、Administration Console の設計が全面的に刷新されています。WebLogic Server 9.0 の Administration Console は、WebLogic Portal のフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。
アーキテクチャが新しくなったため、Administration Console を拡張する手順も新しくなりました。旧リリース用に構築された WebLogic Administration Console の拡張は、新しいインフラストラクチャでは機能しません。
Administration Console の拡張の詳細については、『Administration Console の拡張』(http://edocs.beasys.co.jp/e-docs/wls/docs90/console_ext/index.html) を参照してください。
次の表に、非推奨となった、またはサポートされなくなったリソース アダプタのコンフィグレーション設定を示します。新機能と変更点の詳細については、『Programming WebLogic Resource Adapters』の「New and Changed Features in This Release」(http://edocs.beasys.co.jp/e-docs/wls/docs90/resadapter/intro.html#features) を参照してください。
|
|
|
|
|
|
|
|
|
|
|
|
WLEC は、WebLogic Server 8.1 で非推奨となりました。WLEC ユーザは、『WebLogic Tuxedo Connector 移行ガイド』(http://edocs.beasys.co.jp/e-docs/wls/docs90/wlec_migration/index.html) の説明に従って、アプリケーションを WebLogic Tuxedo Connector に移行する必要があります。
以下のコンフィグレーション フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル モードでのアップグレード」で説明されているように、アップグレード中に [下位互換性フラグを設定しない] オプションを選択して無効にしない限り、下位互換性をサポートするためデフォルトで設定されます。
|
|
|
|
|
この節では、WebLogic Server 9.0 で非推奨となった、または削除された API について説明します。
注意 : 9.0 の環境で WebLogic Server 8.1 MedRec アプリケーションを構築する場合は、medrec/src/common/web/com/bea/medrec/utils/MedRecWebAppUtils.java と medrec/src/clients/com/bea/medrec/webservices/swing/EditProfileFrame.java の 2 つの Java ファイルで、weblogic.webservice.tools.wsdlp パッケージへの参照を新しいパッケージ名である weblogic.webservice.wsdl に置き換える必要があります。
8.1 のパッケージである weblogic.webservice.tools.wsdlp と 9.0 のパッケージである weblogic.webservice.wsdl は公開されていません。
「Web サービス」も参照してください。
非推奨となった API については、『BEA WebLogic Server 9.0 API Reference』の「Deprecated API」(http://e-docs.bea.com/wls/docs90/javadocs/deprecated-list.html) を参照してください。
この節では、WebLogic Server 9.0 で削除された API について説明します。
次の表に、WebLogic Server 8.1 で非推奨となり、WebLogic Server 9.0 で削除された API を示します。
次の表に、WebLogic Server 7.0 で非推奨となり、WebLogic Server 9.0 で削除された API を示します。
次の表に、これまで非推奨となることなく、WebLogic Server 9.0 で削除された API を示します。ここに記載されている API のほとんどは、適用される標準が変更されたため、または WebLogic Server 専用で、外部アプリケーションでは適用できないため、削除されました。
注意 : 表中の * (アスタリスク) はワイルドカード文字です。
|
|
|