| Oracle® Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド 12cリリース1 (12.1.1) B65938-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド 12cリリース1 (12.1.1) B65938-02 |
|
前 |
次 |
この項では、WebLogic Server 12.1.1にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。
このリリースおよび以前のリリースの、『Oracle WebLogic Serverの理解』のWebLogic Serverの互換性に関する項と、『Oracle WebLogic Serverの新機能』も参照してください。
互換性に関する検討事項は、次のように分類されます。すべてのケースにおいて、参照先は次のとおりです。
ユーザーの状況に該当するその他の項は、WebLogic Server 12.1.1にアップグレードする前のWebLogic Serverのバージョンによって異なります。WebLogic Serverの現在のバージョンに基づいて参照する各項の一覧については、表A-1を参照してください。
表A-1 各バージョンのWebLogic Serverからのアップグレードに適用される項
| WebLogic Serverのバージョン | これらの項を参照 |
|---|---|
|
10.3.5 |
ノード・マネージャのstartScriptEnabledのデフォルト WebLogic Server 8.1 Webサービス・スタックの削除 Universal Description and Discover (UDDI)レジストリの削除 PointBaseからDerbyに変更された評価版データベース DataDirectのOracleタイプ4 JDBCドライバの使用 |
|
10.3.3および10.3.4 |
上記のすべての項、および次の項: |
|
10.3.2 |
上記のすべての項、および次の項: |
|
10.3.1 |
上記のすべての項、および次の項: Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダ |
|
10.3 |
上記のすべての項、および次の項: |
|
10.0 |
上記のすべての項、および次の項: |
|
9.2 |
上記のすべての項、および次の項: |
|
9.1 |
上記のすべての項、および次の項: |
|
9.0 |
上記のすべての項、および次の項: |
|
8.1 |
上記のすべての項、および次の項: |
WebLogic Serverの非推奨になった機能に関する情報は、My Oracle Support(https://support.oracle.com/)で入手できます。
WebLogic Server 11g リリース1で非推奨になった機能に関する情報は、My Oracle Support (https://support.oracle.com/)で入手できます。
「ナレッジ・ベースの検索」フィールドに、ドキュメントID888028.1を入力してください。
WebLogic Server 12.1.1で非推奨になった機能に関する情報は、My Oracle Support(https://support.oracle.com/)で入手できます。「Deprecated Features」で検索してください。
表A-2の構成フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル・モードでのアップグレード」で説明されているように、アップグレード中に「下位互換性フラグを設定しない」オプションを選択して無効にしないかぎり、下位互換性をサポートするためデフォルトで設定されます。
表A-2 下位互換性フラグ
| カテゴリ | 下位互換性フラグ | 詳細については、次を参照... |
|---|---|---|
|
セキュリティ |
|
|
|
Webアプリケーション |
|
WebLogic Server 11g以前のドメインをWebLogic Server 12.1.1ドメインにアップグレードする際は、次の操作が必要な場合があります。
Java承認ディレクトリ(JRE_HOME/lib/endorsed)の場所の手動設定
permgen領域および最大permgen領域の手動拡張
次の状況では、Java承認ディレクトリの場所の手動設定は必要ありません。
JDK7を使用中の場合。
WebLogic Server 12.1.1でインストールされたJDKの1つを使用中の場合。
WebLogic Server 12c構成ウィザードによるドメイン作成で生成されたWLS 12cドメインおよび起動スクリプトを使用中の場合、またはWebLogic Serverインストーラでインストールされたように起動スクリプトがcommEnv.cmd/shを参照する場合、あるいはその両方の場合。
この状況がいずれも当てはまらないとき、次のいずれかの状況が当てはまる場合は、管理対象サーバーの起動に使用するコマンドでJava承認ディレクトリの場所を手動設定する必要があります。
管理対象サーバーの起動にノード・マネージャを使用しているが、起動スクリプト(startScriptEnabled=false)を使用していない場合。WebLogic Server 12.1.1以降、startScriptEnabledのデフォルト値はtrueになりました。
カスタム起動スクリプト、つまりOracleで提供されていない起動スクリプトを使用中の場合。
java.weblogic.Serverを使用して空のドメインを作成しようとしている場合。
このいずれのケースでも、管理対象サーバーの起動コマンドにjava.endorsed.dirパラメータを含めてください。
startWeblogic.sh -Djava.endorsed.dir=WL_HOME/endorsed
複数のJava承認ディレクトリを指定する場合は、各ディレクトリ・パスをコロン(:)で区切ります。
|
注意: この項に記述されているオプションではすべて、 |
次のように、startServerを呼び出すときに値をjvmArgsとして渡すか、nmstartを呼び出すときに値をプロパティとして渡すことで、この値を指定することもできます。
wls:/nm/mydomain> prps = makePropertiesObject("Arguments=-Djava.endorsed.dirs=/WL_HOME/endorsed")
wls:/nm/mydomain> nmStart("AdminServer",props=prps)
管理対象サーバーの起動にノード・マネージャを使用している場合は、WLSTまたは管理コンソールを使用して、-Djava.endorsed.dirs=/WL_HOME/endorsed")パラメータをServerStartMBeanのarguments属性に含めることができます。管理コンソールを使用中の場合、サーバーの「構成」>「サーバーの起動」タブでこのパラメータを「引数」フィールドに入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、または管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。
管理対象サーバーの起動時にOutOfMemory: PermGen Spaceエラーが発生した場合は、permgen領域を128MB以上に手動設定し、最大permgen領域を256MB以上に拡張する必要があります。
|
注意: ここで記述されているオプションではすべて、 |
これを実行するには、WLSTまたは管理コンソールを使用して、ServerStartMBeanのarguments属性に次のように指定します。管理コンソールを使用中の場合、サーバーの「構成」>「サーバーの起動」タブでこのパラメータを「引数」フィールドに入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、または管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。
startWeblogic.sh -XX:PermSize=128m -XX:MaxPermSize=256m
次のように、startServerを呼び出すときに値をjvmArgsとして渡すか、nmstartを呼び出すときに値をプロパティとして渡すことで、この値を指定することもできます。
wls:/nm/mydomain> prps = makePropertiesObject("Arguments= -XX:PermSize=128m -XX:MaxPermSize=256m")
wls:/nm/mydomain> nmStart("AdminServer",props=prps)
WebLogic Server 12.1.1以降、startScriptEnabledのデフォルト値はtrueに変更されました。これまでの旧リリースでは、デフォルトはfalseでした。ノード・マネージャで起動スクリプトを使用しない場合は、アップグレード後にこの値をfalseに変更します。
Oracle Kodoは、WebLogic Server 10.3.1から非推奨とされています。WebLogic Server 12.1.1から、Kodoにかわって、EclipseLinkがデフォルトのJPAプロバイダとなっています。WebLogic Server 12.1.1でKodoを永続プロバイダとして引き続き使用するアプリケーションは、更新する必要があります。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミング』の競合を解決するためのアプリケーションの更新に関する項を参照してください。
WebLogic Server 12.1.1から、JPA 2.0のサポートが組み込まれています。JPA 2.0では、ドメイン・モデリング、オブジェクト/リレーショナル・マッピング、EntityManagerインタフェース、問合せインタフェースおよびJava Persistence Query Language (JPQL)などの各機能が向上し、強化されています。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミング』のWebLogic ServerでのJPA 2.0とTopLinkの使用に関する項を参照してください。
WebLogic Server 10.3.2から、EJB 3.0アプリケーションでOracle TopLinkの機能を活用できます。Oracle TopLinkは、高度なオブジェクト永続性およびオブジェクト変換フレームワークであり、開発と保守にかかる労力を削減して、エンタープライズ・アプリケーションの機能性を高める開発ツールと実行時機能を提供します。詳細については、『Oracle Fusion Middleware Oracle TopLink開発者ガイド』を参照してください。
この項では、WebLogic Server 12.1.1から削除されているWebサービス機能、ならびにWebLogic Server 10.3.3以上で追加された新規のWebサービス機能について説明します。
WebLogic Server 8.1 Webサービス・スタックはWebLogic Server 12.1.1リリースで削除されています。したがって、WebLogic Server 8.1 Webサービス・アプリケーションは今後機能しません。これらのアプリケーションは、「8.1のWebLogic Webサービスの12.1.xへのアップグレード」の指示に従って、WebLogic JAX-RPCまたはJAX-WSスタックにアップグレードすることをお薦めします。
Universal Description and Discovery (UDDI)レジストリはWebLogic Server 12.1.1から削除されています。UDDIを引き続き使用中の場合にWebLogic Server 12.1.1にアップグレードする際は、UDDI 3.0に準拠したOracle Service Registry (OSR)に移行することをお薦めします。
リリース10.3.3で、WebLogic Serverには次の機能が追加されました。
Webサービスの原子性トランザクションのサポート。WebLogic Webサービスは、WebSphere、JBoss、Microsoft .NETなどの外部トランザクション処理システムとの相互運用性を実現します。
クラスタ環境でのWebサービスの拡張サポート
Webサービスおよびクライアントの監視の拡張
Fusion Middleware Controlを使用するWebLogic WebサービスへのOracle WSMポリシーの添付
リレーショナル・データベースにアクセスするための宣言Webサービス・ソリューションのEclipseLink DBWSサポート
メソッドレベルのポリシー添付動作の変更: WebLogic Server 10.3.3より前のリリースでは、管理コンソールを使用してWebサービスのメソッドにポリシーを添付すると、そのポリシーはモジュール内のすべてのWebサービスで同じ名前を持つメソッドにも添付されていました。WebLogic Server 10.3.3では、ポリシーは適切なWebサービスのメソッドのみに添付されます。
OWSMポリシー名からのpolicy:接頭辞の削除
Webサービスの「WSDL」タブの削除: WebLogic Server 10.3.3より前のリリースでは、「構成」→「WSDL」タブを選択すると、現在のWebサービスのWSDLを表示できました。「WSDL」タブはWebLogic Server 10.3.3以降では削除されています。
新しい開発ツール: Oracle JDeveloperおよびOracle Enterprise Pack for Eclipse (OEPE)。
Oracle Enterprise Manager Fusion Middleware Controlとの統合
Oracle WebLogic Services Manager (WSM)セキュリティ・ポリシーのサポート
JAX-WSでのWS-SecureConversation 1.3、およびJAX-WSでのWS-SecurityによるMTOMのサポート
詳細は、『Oracle WebLogic Serverの新機能』のWebサービスに関する項を参照してください。
この項では、様々なWebLogic Serverリリースについて行われているセキュリティの変更について説明します。
この項では、様々なWebLogic Serverバージョンについて行われているSSLの変更について説明します。
WebLogic Server 12.1.1から、Certicom SSLの実装は削除されています。この変更によって、『Oracle WebLogic Serverの保護』のSSLの構成に関する項に記述されているように、システム・プロパティの更新とスイッチのデバッグが必要になる場合があります。
SSLMBeanはWebLogic Server 10.3.5から、JSSEアダプタを有効化または無効化する機能など追加のSSL構成機能をサポートするように変更されています。
詳細については、以下のマニュアルを参照してください。
JSSE SSL実装がWebLogicシステム・プロパティを扱う方法の相違点の一覧は、『Oracle WebLogic Serverの保護』のJSSE SSL実装とCerticom SSL実装のシステム・プロパティの相違に関する項を参照してください。
WebLogic ServerでのSSLサポートの詳細は、『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。
JSSEの詳細は、『Java Secure Socket Extension (JSEE) Reference Guide』(http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。
WebLogic Server 10.3.3から、Java Secure Socket Extension (JSSE)がSSL実装として導入されています。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングI/O API、ノンブロッキングI/O API、および複数の信頼性のあるCAを含む参照実装が含まれています。
リリース10.3.3では、WebLogic Serverにスレッド・セーフなデプロイ可能認可プロバイダおよびロール・マッピング・プロバイダのデプロイメント・パフォーマンス拡張が含まれます。WebLogic Serverはデフォルトで、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対してスレッド・セーフな並列変更を実行できます。このため、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。
ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされていない場合は、セキュリティ・ポリシーとロールの並列変更を無効にし、かわりに同期メカニズムを強制的に使用する必要があります。この場合、各アプリケーションとモジュールはキューに入り、順番にデプロイされます。この同期強制メカニズムは、管理コンソールまたはRealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性を使用することで有効にできます。
詳細は、『Oracle WebLogic Serverの保護』のデプロイメント時のセキュリティ・ポリシーとロール変更での同期の有効化に関する項を参照してください。
Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダという2つの新しいLDAP認証プロバイダがWebLogic Server 10.3.2に追加されました。これらの認証プロバイダを使用すると、Oracle Internet Directory LDAPサーバーとOracle Virtual Directory LDAPサーバーにユーザーとグループを格納したり、両サーバーからユーザーとグループを読み取ったりできます。
これらの新しいセキュリティ・プロバイダの構成と使用の詳細は、『Oracle WebLogic Serverの保護』のLDAP認証プロバイダの構成に関する項を参照してください。
WebLogic Server 10.3では、SAML 2.0をサポートするため、SAML 2.0資格証明マッピング・プロバイダおよびSAML 2.0 IDアサーション・プロバイダが追加されました。これらの新しいプロバイダはそれぞれ、次を利用する場合にSAML 2.0アサーションの生成および消費に使用することができます。
SAML 2.0 Webシングル・サインオン・プロファイル
WS-Security SAMLトークン・プロファイル・バージョン1.1
SAML 2.0 Webシングル・サインオンでは、SAML 2.0資格証明マッピング・プロバイダで生成されるアサーションを消費できるのは、SAML 2.0 IDアサーション・プロバイダのみです。これらはSAML 1.1アサーションと互換性がありません。
SAML Token Profile 1.1は、リリース10.3のWebLogic Server Webサービスからサポートされるようになりました。また、SAML 2.0およびSAML 1.1アサーションがサポートされ、SAMLトークン・プロファイル1.0との下位互換性も保たれます。SAMLトークンのWebサービスに対する構成は、適切なWS-SecurityPolicyアサーションを利用して行います。
|
注意: SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。以前の「WebLogic Server 9.2セキュリティ・ポリシー」では、SAML Token Profile 1.0/SAML 1.1のみがサポートされます。 |
WebLogic Server 10.3では、次のセキュリティ・プロバイダで使用されるデータ・ストアとして、外部RDBMSを使用できるようになりました。
XACML認可プロバイダ
XACMLロール・マッピング・プロバイダ
SAML 1.1の次のプロバイダ
SAML IDアサーション・プロバイダV2
SAML資格証明マッピング・プロバイダV2
SAML 2.0の次のプロバイダ
SAML 2.0 IDアサーション・プロバイダ
SAML 2.0資格証明マッピング・プロバイダ
WebLogic資格証明マッピング・プロバイダ
PKI資格証明マッピング・プロバイダ
証明書レジストリ
このデータ・ストアはRDBMSセキュリティ・ストアと呼ばれますが、クラスタなどのドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを使用する場合に強くお薦めします。ドメイン内にRDBMSセキュリティ・ストアが構成されている場合、セキュリティ・レルム内に作成されている上記のいずれかのセキュリティ・プロバイダのインスタンスは、自動的にRDBMSセキュリティ・ストアのみをデータ・ストアとして使用し、組込みLDAPサーバーは使用しません。ドメイン内に構成されている上記のリスト以外のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します。たとえば、WebLogic認証プロバイダは組込みLDAPサーバーを使用します。
RDBMSセキュリティ・ストアを使用するには、まず、ドメインを作成して外部RDBMSサーバーを構成します。ドメインを起動する前に、RDBMSセキュリティ・ストアで必要になる表をデータ・ストア内に作成します。WebLogic Serverインストール・ディレクトリには、サポート対象のデータベースごとに、これらの表を作成する一連のSQLスクリプトが含まれています。
RDBMSセキュリティ・ストアを使用したいドメインが作成済であっても、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。既存のドメインにはRDBMSセキュリティ・ストアを組み込まないでください。詳細は、『Oracle WebLogic Serverの保護』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。
Windows NT認証プロバイダは、WebLogic Server 10.0以降では非推奨となっています。かわりに、それ以外のサポート対象の1つまたは複数の認証プロバイダを使用してください。
WebLogic Server 9.2では、SAML 1.1をサポートするため、SAML資格証明マッピング・プロバイダおよびSAML IDアサーション・プロバイダの新バージョンが追加されました。SAML資格証明マッピングV1プロバイダおよびSAML IDアサーションV1プロバイダは非推奨となったため、SAML資格証明マッピング・プロバイダおよびSAML IDアサーション・プロバイダの各V2バージョンを使用してください。
各プロバイダのバージョン番号は加算されてV2になっていますが、新しいSAMLセキュリティ・プロバイダにも、V1プロバイダと同じSAML 1.1標準が実装されています。
|
注意: Webシングル・サインオンに関して、この項で説明しているSAML 1.1プロバイダは、SAML 2.0サービスが構成されているWebLogic Serverインスタンスとは互換性がありません。 |
WebLogic Server 9.1には、XACML認可プロバイダおよびXACMLロール・マッピング・プロバイダという2つの新しいセキュリティ・プロバイダが含まれています。WebLogic Serverの以前のリリースでは、独自のセキュリティ・ポリシー言語に基づいた認可プロバイダとロール・マッピング・プロバイダを使用していました。これらのXACMLセキュリティ・プロバイダでは、OASISの標準規格XACML (eXtensible Access Control Markup Language)2.0をサポートしています。これらのプロバイダでは、標準のXACML 2.0関数、属性、スキーマ要素で表現されたポリシーを、インポート、エクスポート、永続化および実行できます。
WebLogic Server 9.1以降を使用して作成したWebLogicドメインには、XACMLプロバイダがデフォルトで含まれています。これら新しいXACMLプロバイダは、WebLogic認可プロバイダ(DefaultAuthorizer)およびWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)で作成したポリシーやロールに対して完全な互換性があります。既存のWebLogicドメインを12.1.1にアップグレードして、現在指定されている認可プロバイダおよびロール・マッピング・プロバイダ(サード・パーティ・パートナのプロバイダ、オリジナルのWebLogic認可プロバイダおよびロール・マッピング・プロバイダなど)を引き続き使用できます。WebLogic Server独自のプロバイダを使用している既存ドメインを、必要に応じてXACMLプロバイダに移行することもできます(既存ポリシーのバルク・インポートも含む)。詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverのセキュリティの理解に関する項を参照してください。
表A-3に、WebLogic Server 9.0におけるセキュリティMBeanの変更点を示します。
表A-3 WebLogic Server 9.0におけるセキュリティMBeanの変更点
| セキュリティMBeanのタイプ | 説明 |
|---|---|
|
すべてのセキュリティMBean |
WebLogic Server 8.1では、セキュリティMBean属性を更新すると、値はセキュリティ構成と管理階層ではただちに有効になり、セキュリティ実行時階層ではサーバーを再起動すると有効になっていました。 WebLogic Server 9.0からは、セキュリティMBean属性の変更が構成、管理、および実行時階層でただちに有効になるか、サーバーを再起動すると有効になるかについては、この属性を動的な属性として設定するか動的でない属性として設定するかによって制御されます。詳細については、「動的構成管理」を参照してください。 |
|
|
セキュリティ・プロバイダMBeansの場合(のみ)
|
|
すべてのカスタム・セキュリティ・プロバイダMBean |
|
権限のないアクセスからパスワードなどの重要なデータを保護するために、構成MBeanのいくつかの属性は暗号化されます。属性の値は、ドメインの構成ファイルに暗号化された文字列として保持されます。メモリー内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリーから盗用されるリスクが軽減され、セキュリティがさらに強化されます。
9.0より前のリリースでは、クリア・テキスト形式または暗号化形式で、パスワードなどの暗号化する属性をconfig.xmlファイルで指定することができました。この場合、起動時にWebLogic Serverは、次回ファイルに書き込むときに情報を暗号化します。
WebLogic Server 9.0から、本番モードのときは、パスワードなどの暗号化する属性は構成ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア・テキスト形式または暗号化形式のどちらでもかまいません。
次のように、weblogic.security.Encryptコマンド・ライン・ユーティリティを使用してパスワードを暗号化することができます。
java weblogic.security.Encrypt
ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。
このユーティリティの対象は、構成ファイルのパスワードだけではありません。これは、記述子ファイル(JDBCまたはJMS記述子など)およびデプロイメント・プランでパスワードを暗号化する場合にも使用できます。詳細は、Oracle WebLogic Serverのコマンド・リファレンスの「encrypt」を参照してください。
デフォルトでは、WebLogic ServerのインスタンスがHTTPリクエストに応答するとき、HTTPレスポンス・ヘッダーにWebLogic Serverのサーバー名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0より前のリリースとは異なります。
HTTPリクエストに応答するときにサーバー名とバージョン番号をHTTPレスポンス・ヘッダーに含めるには、管理コンソールでWebLogic Serverインスタンスの「サーバー・ヘッダーの送信」属性を有効にします。この属性は、「サーバー」→「サーバー名」→プロトコル→「HTTP」タブの詳細オプション・セクションにあります。この機能を有効にすると、攻撃者がWebLogic Serverの特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティ・リスクが発生する可能性があります。
セキュリティを確保する方法の詳細は、『Oracle WebLogic Server本番環境の保護』の本番環境の保護に関する項を参照してください。
9.0より前のリリースのWebLogic Serverでは、MBeanHomeへの匿名アクセスがデフォルトで可能でした。WebLogic Server 9.0以降では、セキュリティが強化されているため、MBeanHomeへの匿名アクセスはできなくなりました。
これは推奨されませんが、サーバーを起動するときに次のフラグを指定することにより、匿名アクセスを再び有効にすることができます。
-Dweblogic.management.anonymousAdminLookupEnabled
WebLogic Server 9.0から、Webサービスにおけるメッセージ・レベルのセキュリティが強化され、標準ベースのWeb Services Policy Framework (WS-Policy)を使用するようになりました。WS-Policyでは、XML Webサービス・ベースのシステム内にあるエンティティについての機能、要件、一般的な特性を表現する、柔軟で拡張性のある文法を使用できます。WS-Policyの詳細は、『Webサービスのためのセキュリティおよび管理者ガイド』のWS-SecurityPolicy 1.2ポリシー・ファイルの使用に関する項を参照してください。
8.1における実装は、Web Services Security (WSS)標準のOASISによる実装がベースとなっていました。この実装は9.0以降でも下位互換性のためにサポートされていますが、非推奨となっています。詳細については、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wssを参照してください。
次の項では、WebLogic Server 12.1.1におけるWebアプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。
WebLogic Server 12.1.1インストーラにはCoherence 3.7.1が含まれています。クラスタ内のサーバーはすべて同じバージョンのCoherenceを使用する必要があります。したがって、クラスタ内のすべてのキャッシュ・サーバーをCoherence 3.7.1にアップグレードします。
WebLogic Server 12.1.1から非推奨またはサポート対象外となったWebアプリケーション機能については、次を参照してください。
WebLogic Server 11g リリース1で非推奨になった機能に関する情報は、My Oracle Support (https://support.oracle.com/)で入手できます。
「ナレッジ・ベースの検索」フィールドに、ドキュメントID888028.1を入力してください。
WebLogic Server 12.1.1で非推奨になった機能に関する情報は、My Oracle Support(https://support.oracle.com/)で入手できます。「Deprecated Features」で検索してください。
WebLogic Server 10.3.3以降では、WebLogic ServerにデプロイされているアプリケーションでのCoherenceデータ・キャッシュの使用が容易になり、セッション管理用のCoherence*WebとTopLink Gridをobject-to-relational永続フレームワークとしてシームレスに取り込めるようになりました。これらの機能の総称がActiveCacheです。
ActiveCacheでは、レプリケートおよび分散されたデータ管理とキャッシングのサービスが提供されており、このサービスを使用することで、アプリケーションのオブジェクトとデータをCoherenceクラスタ内のすべてのサーバーに対して利用可能にすることができます。
詳細は、ActiveCacheの使用を参照してください。
リリース10.3.3で、WebLogic Serverでクラス・キャッシュを有効にできるようになりました。クラス・キャッシュを使用する利点を次に示します。
サーバーの起動時間が短縮されます。
パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。
クラス・キャッシュが開発モードでサポートされるのは、startWebLogicスクリプトを使用してサーバーを起動したときです。クラス・キャッシュはデフォルトでは無効になっており、本番モードではサポートされません。起動時間の短縮の程度は様々なJREベンダーによって異なります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシュの構成に関する項を参照してください。
WebLogic Server 10.0以降では、この項および『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のjsp-descriptorに関する項で説明されているように、WebLogic Server 9.2以前のリリースに対する下位互換性はjsp-descriptor要素内のbackward-compatible要素を使用してサポートされます。
JSP 2.1はWebLogic Server 10.0からサポートされています。Webアプリケーションのバージョン(バージョン2.4または2.5)とbackward-compatible要素の設定に応じて、WebLogic Server 10.0以降でもJSP 2.0がサポートされます。
バッファの接尾辞の設定およびサーブレット2.5パッケージの暗黙的なインポートについては、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の下位互換性フラグに関する項を参照してください。
「下位互換性フラグ」で説明されているように、JSP 2.0はWebLogic Server 9.0以降でサポートされています。JSP 2.0のサポートに応じて、JSPの動作は次のように変更されています。
JSPがセッションに参加していない場合(またはJSPが参加しているセッションが無効な場合)、次のコマンドが実行されると、IllegalStateExceptionがスローされます。
PageContext.getAttribute(name, PageContext.SESSION_SCOPE)
この例外は、このようなエラーが重要な問題でない場合は、捕捉して無視することができます。
JspWriterImplがprintline関数ごとに\nをSystem.getProperty("line.separator")に置き換えるようになりました。この置換により、以下に該当するJSPで問題が発生します。
新しい行に表示される複数のpageディレクティブを含みます。例:
<%@ page import="com.foo.bar.*" %> <%@ page import="com.foo.xyz.*" %> ...
XML形式で出力を生成します。
pageディレクティブに続いてXML宣言を生成します。
Windowsシステムからサービスを受けています。この場合、pageディレクティブごとに\r\nが出力されます。
Internet Explorerを使用して表示されます。
Internet Explorerで表示される場合、各pageディレクティブが空の\r\nを出力し、XML宣言(<?xml version="1.0" encoding="iso-8859-1"?>)が新しい行の後ろに表示されます。Internet Explorerは、宣言が検出されず、ページはコンパイルできるが表示できないことを通知するエラー・メッセージを表示します。
JspWriterImplに対する変更により生じた問題を解決するには、次のタスクのどちらかまたは両方を実行します。
ページの最上部でXML宣言を定義します。
次のように、pageディレクティブを1つの宣言にグループ化します。
<%@ page import="com.foo.bar.*, com.foo.baz.*" contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %>
JSP <param name>タグで実行時の式の値を使用できなくなりました。例:
<jsp:param name="<%= AdminActions.RETURN_LINK %>" value="<%= returnlink %>" />
表5-1の「アップグレード・オプションの選択」行で説明されているように、ドメインのアップグレード中に「下位互換性フラグを設定しない」アップグレード・オプションを無効にするか、次のようにweblogic.xmlファイルでbackwardCompatibleフラグを有効にすることで、引き続きこの機能をサポートできます。
<jsp-descriptor> <jsp-param> <param-name>backwardCompatible</param-name> <param-value>true</param-value> </jsp-param> </jsp-descriptor>
WebLogic Serverバージョン9.2以降では、ターゲット・リソースにおいてアクセス制御が有効になっていない場合でも、HTTP BASIC認証を使用するクライアント・リクエストはWebLogic Server認証を通過しなければなりません。
この動作は、セキュリティ構成MBeanフラグ"enforce-valid-basic-auth-credentials"で指定します。(DomainMBeanを使用すると、そのドメインの新しいセキュリティ構成MBeanを取得できます。)このフラグは、非セキュアなリソースへのアクセスにおいて、無効なHTTP BASIC認証資格証明によるリクエストを許可するかどうかを指定します。
|
注意: セキュリティ構成MBeanは、ドメイン全体のセキュリティ構成情報を提供します。 |
enforce-valid-basic-auth-credentialsフラグはデフォルトでtrueに設定されており、WebLogic Server認証が実行されます。認証に失敗すると、リクエストは拒否されます。したがって、ユーザーおよびパスワードの情報がWebLogic Serverに保持されている必要があります。
詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のリソースが非セキュアな場合のBASIC認証に関する項を参照してください。
Javaサーブレットの仕様バージョン2.3の時点で、次の構文がマッピングの定義に使用されています。
/(スラッシュ)文字だけが含まれるサーブレット・パス文字列は、アプリケーションのデフォルト・サーブレットを表します。サーブレット・パスは、リクエストURIからコンテキスト・パスを削除したパス(この場合はnull)に解決されます。
1個の*(アスタリスク)で始まる文字列は、拡張子マッピングを指定します。
これらの変更により、次のHttpServletRequestメソッドの動作に変化が生じます。
getPathInfo
getServletPath
動作の変更を説明するために、例として/abc/def.htmlというリクエストがServletAに解決される場合を考えます。
/がServletAにマップされると、servletPath="abc/def.html"およびpathInfo=nullになります。
/*がServletAにマップされると、servletPath=""およびpathInfo="abc/def.html"になります。
確実にnullでないパス情報が返されるようにするには、/(スラッシュ)のサーブレット・マッピング文字列が出現するすべての箇所を/*に置換します。
Javaサーブレット仕様は、次の場所からダウンロードできます。
http://www.oracle.com/technetwork/java/javaee/servlet/index.html
WebLogic Server 10.3.3以降では、WebLogic Serverインストール・プログラムの評価版データベースがPointBaseからApache Derbyに変更されています。「製品とコンポーネントの選択」画面の評価版データベース・オプションを選択すると、DerbyデータベースがWL_HOME\common\derbyディレクトリにインストールされます。「標準」インストールを選択すると、Derbyがデフォルトでインストールされます。
PointBaseに基づくドメインがあり、ドメインをWebLogic Server 10.3.3以降にアップグレードした後も引き続きPointBaseを使用する場合は、PointBaseのライセンスをhttp://www.pointbase.comで入手する必要があります。フルWLSインストーラではPointBaseインストール・ディレクトリが保存されません。PointBaseを使用するかわりに、ドメイン・データベースをDerbyに移行できます。
詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください。
以降の項では、JDBCサポートの変更点について説明します。
新しいJDBC機能の詳細は、『Oracle WebLogic Serverの新機能』のJDBCに関する項を参照してください。
操作性とパフォーマンスを向上させるため、WebLogic Server 12.1.1以上ではデータ・ソース・プロファイル・ログを使用してイベントが格納されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のWebLogic JDBCリソースの監視に関する項を参照してください。
WebLogic Server 12.1.1では、GridLinkデータ・ソースによってセッション・アフィニティ・ポリシーが使用され、パフォーマンスの向上のためにサーブレット・セッションのデータベース操作がRACクラスタ内の同じRACインスタンスに指示されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のGridLinkアフィニティに関する項を参照してください。
WebLogic Server 12.1.1では、アプリケーションでラベリングを使用することで、任意の名前/値のペア(ラベル)を特定の初期化状態の接続にアタッチできます。これによって接続を再初期化する時間とコストが最小限に抑えられるため、アプリケーションにおけるパフォーマンスが向上します。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の接続のラベリングに関する項を参照してください。
WebLogic Server 12.1.1では、UCPおよびONSはインストールに含まれなくなりました。UCPおよびONSのデバッグの設定方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のUCP/ONSのデバッグの設定に関する項を参照してください。
WebLogic Server 12.1.1から、DataDirectのOracleタイプ4 JDBCドライバは、WebLogicブランドのDataDirectドライバと呼ばれるようになりました。オラクル社では『Oracle WebLogic Serverタイプ4 JDBCドライバ』のドキュメントの提供を停止するため、DataDirectドライバの詳細情報は今後提供されなくなります。WebLogic Server環境におけるWebLogicブランドのDataDirectドライバの構成および使用方法については引き続き、『Oracle WebLogic Server JDBCのプログラミング』のWebLogicブランドのDataDirectドライバの使用に関する項で情報を提供します。ドライバの動作の詳細はDataDirectのドキュメントを確認することをお薦めします。『Progress DataDirect for JDBC User's Guide Release 4.2』および『Progress DataDirect for JDBC Reference Release 4.2』(http://www.datadirect.com/index.html)を参照してください。
次のJDBCドライバは非推奨となりました。
Oracle用のWebLogicタイプ4 JDBCドライバ
このドライバは、WebLogic Server 10.3で非推奨になり、削除されています。この非推奨のドライバのかわりに、WebLogic Serverにも付属しているOracle Thin Driverを使用してください。Oracle Thin Driverの詳細は、『Oracle WebLogic Serverタイプ4 JDBCドライバ』のWebLogic Serverでのサード・パーティJDBCドライバの使い方に関する項を参照してください。
Sybase Jconnect 5.5および6.0ドライバ。これらのドライバは、サンプル・コードのデフォルト・インストールに関するOracleセキュリティ・ポリシーに従ってリリース10.3.3の時点でWebLogic Serverから削除されました。これらのドライバはSybaseからダウンロードできます。また、WebLogic Serverに付属しているOracleブランドのSybase用JDBCドライバを使用することもできます。
WebLogic Server 10.3.1以上のリリースでは、capacityIncrement属性は構成可能ではなく、1という値に設定されます。
10.3以降のWebLogic Serverは、JDBC 4.0仕様に準拠しています。ただし、次の拡張と例外を含みます。
サーバー側では、SQLXMLが完全にサポートされています。RMIクライアント側では、SQLXMLを部分的にサポートしています。クライアント側で、API getSourceとsetResultを使用することはできません。
WebLogic Server JDBCでは、標準のラッパー・パターン機能がサポートされており、サーバー側の機能を拡張します。JDBC標準では、インタフェースにラッパー操作のサポートが必要になります。WebLogic Serverでは、サーバー側の具象クラスとインタフェースの両方でラッパー操作がサポートされます。
WebLogic Serverでは、次のように文プール管理が拡張されます。
Statementインタフェースの場合:
isPoolable()呼出しは常にfalseを返します。
setPoolable()呼出しはプール可能状態を変更しません。
PreparedStatementおよびCallableStatementインタフェースの場合:
isPoolable()呼出しは現在のプール可能状態を返します。デフォルト値はtrueです。
setPoolable()呼出しはプール可能状態を変更します。
PreparedStatementまたはCallableStatementインタフェースの場合、close()メソッドを呼び出すと、次のことが起こります:
現在のプール可能状態がfalseの場合、PreparedStatementまたはCallableStatementが閉じられます。
現在のプール可能状態がtrueの場合、PreparedStatementまたはCallableStatementが文キャッシュに戻ります。
更新されたサード・パーティJDBCドライバ:
Oracle Thin Driverが10gから11gに更新されました。
PointBaseデータベース・サーバーとドライバが5.1から5.7に更新されました。
WebLogic Serverに付属しているWebLogicブランドのDataDirectドライバは、DataDirectから提供されています。10.3においてDataDirectバージョン3.7に変更されました。これらのドライバの変更やJDBC 4.0のサポートの詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogicブランドのDataDirectドライバの使用に関する項を参照してください。
JMSの次の変更に注意してください。
WebLogic Server 12.1.1から、デフォルトのメッセージング・モードがマルチキャストからユニキャストに変更されました。
WebLogic Server 9.0からJMS構成はモジュールとして格納されています。これは、新しいweblogic-jmsmd.xsdスキーマに準拠するXMLドキュメントで定義されます。JMSリソースのモジュール式デプロイメントにより、アプリケーションとJMS構成を別の環境にプロモートできます。たとえば、アプリケーションとそれに必要なJMS構成を、EARファイルを開くことなく、またJMSを手動で再構成することなく、テスト環境から本番環境にプロモートできます。
詳細については、次を参照してください:
WebLogic JMSの構成と管理ガイドのこのリリースでのJMSの新機能と変更点に関する項(WebLogic Server 9.0版はhttp://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/intro.html#WhatsNewJMS)
『Oracle WebLogic Server JMSの構成と管理』のJMSリソースの構成に関する項
『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項
WebLogicアップグレード・ウィザードは、9.0より前のバージョンのJMSリソースを、ドメインのconfig\jmsディレクトリにコピーされるinterop-jms.xmlという名前のJMS Interopモジュール・ファイルに自動的に変換します。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMS Interopモジュールに関する項を参照してください。
JMS構成は次のように変更されています。
新しいJMSリソースを生成するとき、JMSモジュールですべての属性を定義する必要があります(つまり、9.0より前のバージョンの構成ファイルを使用しません)。
「永続ダウングレードを許可」オプションにより、永続ストアが構成されていないJMSサーバーにターゲット指定されている宛先に対して、永続メッセージを送信する場合に、JMSクライアントが例外を取得するかどうかを指定することができます。このオプションは、旧リリースとの下位互換性のために用意されています。
デフォルトでは、このオプションはfalseに設定されており、この場合、ストアが構成されていないJMSサーバーに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションをtrueに設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、「ストアを有効化」パラメータが無効化されている場合(つまり、falseに設定されている場合)にのみ有効です。
詳細は、Oracle WebLogic Server MBeanリファレンスのJMSServerBeanのAllowsPersistentDowngradeに関する項を参照してください。
デフォルトで、JMSサーバーの「一時的なテンプレート」属性が作成されます。旧リリースでは、デフォルトのテンプレートは提供されていませんでした。JMSサーバーの「一時的なテンプレート」属性を使用して一時的なテンプレートを構成することもできます。
「一時的な宛先をホスト」属性を設定して、一時的な宛先をホストするのにJMSサーバーを使用できるかどうかを指定することができます。旧リリースでは、一時的な宛先をホストするのにJMSサーバーを使用するには、「一時的なテンプレート」属性を設定する必要がありました。
分散宛先のJMSテンプレートは、WebLogic Server 9.0の時点でサポートされていないため無視されます。WebLogic Server 9.0以降、この機能は共通分散宛先に置き換えられます。詳細は、Oracle WebLogic ServerのJMSの管理と構成ガイドの共通分散宛先の作成に関する項を参照してください。
JMS接続ファクトリのAllowCloseInOnMessage属性は、デフォルトで有効化されています。詳細は、Oracle WebLogic Server MBeanリファレンスの「ClientParamsBean」を参照してください。
DeliveryFailureParamsBeanのgetExpirationLoggingPolicy属性は非推奨となりました。『Oracle WebLogic Server JMSの構成と管理』のメッセージ・ライフ・サイクルのロギングに関する項の説明に従って、メッセージのライフ・サイクル情報をロギングする機能を使用するようアプリケーションを更新することを推奨します。getExpirationLoggingPolicy属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要があります。
JMSメッセージIDの形式は、WebLogic Server 9.0で変更されています。既存のコンシューマ、プロデューサ、およびサーバーで使用されている9.0より前のバージョンの形式は、引続きサポートされます。たとえば、既存のJMSコンシューマは、新しいJMSプロデューサまたはJMSサーバーから送信されたメッセージであっても、引続き9.0より前のバージョンの形式で確認することができます。
WebLogic Server 9.0以降では、メッセージ負荷のピーク時にJVMヒープ・スペースを解放するメッセージ・ページング機能が、JMSサーバーでは常に有効に設定されています。また、ページ・アウトされたメッセージは、使用しているファイル・システムのディレクトリに格納できるため、管理者は専用のメッセージ・ページング・ストアを作成する必要はありません。ただし、最適なパフォーマンスを維持するには、メッセージのページング先のディレクトリをJMSサーバーの永久ストアが使用する以外のディレクトリに指定する必要があります。
Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのメッセージのページングによるメモリーの解放に関する項を参照してください。
この項では、WebLogic Server 12.1.1にアップグレードする際に認識が必要なメッセージの変更について説明します。
WebLogic Server 10.3.3から、weblogic.jms.extensions.WLMessageインタフェースの次の内部メソッドが、Oracle WebLogic Server APIリファレンス・ガイドから削除されています。
public void setSAFSequenceName(String safSequenceName); public String getSAFSequenceName(); public void setSAFSeqNumber(long seqNumber); public long getSAFSeqNumber();
アプリケーションでこれらの内部メソッドを使用しないでください。内部メソッドは、将来のリリースで予告なしに変更または削除される場合があります。
WebLogic Server 10.3.3から、WebLogicファイル・ストアの動作とチューニング方法は、デフォルト・ファイル・ストアとカスタム・ファイル・ストアについて変更されています。
WebLogic Server 10.3.1では、BEAホーム・ディレクトリがMiddlewareホームに変更されました。このディレクトリのデフォルト・パスは<drive:>Oracle/Middlewareです。この変更がWebLogic Serverに及ぼす影響は次のとおりです。
10.3.1の複数のWebLogicスクリプトに、Middlewareホームを表すための新しい環境変数MW_HOMEが導入されています。この変数が設定されているディレクトリは通常はBEA_HOMEと同じで、これまでどおりWebLogic Serverスクリプトで使用できます。
インストール時のデフォルトでは、WebLogic Serverのインストール・ディレクトリのルート製品として<drive:>Oracle/Middlewareが選択されます。ただし、既存のWebLogic Serverが検出された場合は、デフォルトでそのインストール・ディレクトリが選択されます。
現在、WebLogic Server 10.3.1のドキュメントでは、BEAホームではなくMiddlewareホームという用語を使用します。ただし、この変更は用語のみに適用されます。WebLogicソフトウェア、カスタム・ドメインまたはアプリケーションの移動や、それらの場所を表す既存の環境変数の変更は必要ありません。
この変更によって、コンピュータ上の既存のWebLogic Serverインストール、カスタム・ドメイン、アプリケーションまたはスクリプトが影響を受けることはありません。従来どおりBEA_HOME環境変数を使用し続けることができます。
以降の項では、JTA機能の変更点について説明します。
WebLogic Server 10.3.1以降では、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。
詳細は、『Oracle WebLogic Server JTAのプログラミング』のXAResourceのトランザクションへの参加の登録に関する項を参照してください。
ドメイン・レベルのJTA構成オプションはすべて従来の構成ファイルから保持されています。サーバー・レベルでのみ変更があります。WebLogic Server 9.0から、トランザクション・マネージャでは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・レコードを保存します。アップグレード中、アップグレード・ウィザードは、トランザクション・ログ・レコードをデフォルト・ストアにコピーします。既存のサーバー構成に基づいて設定されるトランザクション・ログ・ファイルの接頭辞は、アップグレード中にトランザクション・ログ・ファイル({.tlog)を検索する目的にのみ使用され、アップグレード後は保持されません。
ドメイン全体が1つのコンピュータにある場合、アップグレード・ウィザードは、初期ドメイン・アップグレードにおいて、すべての管理対象サーバーのアップグレードを処理します(トランザクション・ログ・レコードをデフォルト・ストアにコピーします)。管理対象サーバーが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバーを個別にアップグレードする必要があります。
次の点に注意してください。
明示的なアップグレードが実行される場合(「ドメインのアップグレード」を参照)、トランザクション・リカバリはアップグレード・プロセス中には実行されませんが、サーバーを起動すると実行されます。
暗黙的なアップグレード(付録E「管理サーバー起動時におけるドメインのアップグレード(暗黙モード)」を参照)が実行される場合、トランザクション・リカバリはサーバー起動プロセスにおいて実行されます。
トランザクション・リカバリ・サービスの移行の準備においてトランザクション・ログ・ファイルをネットワーク・ストレージに配置した場合、アップグレード後、ログ・ファイルの場所は保持されません。このリリースでは、WebLogic Serverトランザクション・マネージャは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・ファイルを保存します。デフォルトのWebLogic永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DATファイルを現在のデフォルト・ストアのデフォルトの場所からデフォルト・ストアの新しい場所に手動でコピーする必要があることに注意してください。
トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインを構成する必要があります。詳細は、『Oracle WebLogic Server JTAのプログラミング』のドメイン間トランザクションに対するドメインの構成に関する項を参照してください。
以降の項では、管理コンソールに対する変更点について説明します。
WebLogic Server 10.3で管理コンソールの動作を構成するためのオプションが追加され、次のことを実行できるようになりました。
編集セッション中に他のアカウントによって変更されずに、構成を変更できるように、ドメイン構成をロックする
管理コンソール、UDDI、およびUDDIエクスプローラなどの内部アプリケーションを、サーバーの起動時ではなく、必要に応じて(最初のアクセス時に)デプロイするかどうかを指定する
バナー・ツールバー領域に新たに追加された検索機能を利用して、この検索で指定した文字列が名前に含まれるWebLogic Server構成MBeanを検索する
障害が発生したサーバーやサービスを別のサーバーへ自動的に移行する追加機能を利用する
Service Component Architecture (SCA)デプロイメントをデプロイおよび制御する
Springアプリケーションを検査する
詳細については、WebLogic Server 10.3リリース・ノートの「WebLogic Serverの新機能」を参照してください。
WebLogic Serverバージョン9.0の管理コンソールは、WebLogic Portalのフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。アーキテクチャが新しくなったため、管理コンソールを拡張する手順も新しくなりました。9.0よりも前のWebLogic Serverのリリース用に構築されたWebLogic Serverコンソールの拡張は、新しいインフラストラクチャでは機能しません。
WebLogic Server 10.3.2には次の機能が追加されました。
サンプルのルック・アンド・フィールが提供されています。サンプルを変更して、WebLogic Server管理コンソールのカスタムのルック・アンド・フィールを作成できます。
オンライン・ヘルプは作成し、console拡張に関連付けることができます。
WebLogic Server管理コンソールの拡張の詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドを参照してください。
WebLogic Serverバージョン9.2では、コンソール拡張が次のように変更されています。
このリリース以前の管理コンソール拡張機能では、タグ・ライブラリ・ファイルのサード・パーティJSPタグ・ライブラリへのパス名を指定することにより、それらのライブラリのインポートが可能でした。たとえば、次のようになります。
<%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %>
WebLogic Serverインストールからサード・パーティJSPタグ・ライブラリを使用する管理コンソール拡張機能では、10.0より、タグ・ライブラリを指定する定義済みの絶対URIを使用する必要があります。例:
<%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %>
管理コンソールのweb.xmlファイルが、WebLogic Serverインストール内部のタグ・ライブラリにURIをマップします。このマッピング機能によって、ユーザーがJSPを変更しなくても、タグ・ライブラリのインストール・ディレクトリが認識されます。
古いパス名構文を使用してApache Struts、Apache Beehive、またはJSTLタグ・ライブラリをインポートするすべての管理コンソール拡張機能では、パス名をすべて新しいURIに更新する必要があります。
WebLogic Serverのコンソール拡張機能タグ・ライブラリ(console-html.tld)のURIは変更されていません(/WEB-INF/console-html.tld)。
詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドのJSPテンプレートとタグ・ライブラリに関する項を参照してください。
規則により、ポータル・インクルード・ファイル(.pinc)はポータル・ブック・ファイル(.book)という名前に変更されました。
WebLogic Portalでは、すべての明示的なスケルトンURI参照を、Webアプリケーションを基準として完全修飾する必要があります。ただし、ドキュメントや一部のコンソール拡張例では、これらのスケルトンを基準とした相対参照が使用されていることがあります。次の不適切な例について検討します。
<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="singlelevelmenu_children2.jsp"/>
この例を正しく指定するには、次のようにします。
<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="/framework/skeletons/default/singlelevelmenu_children2.jsp"/>
このリリースでは、相対スケルトンURI参照を引続き使用できます。ただし、今後のリリースではこれらの相対参照は正しく機能しない可能性があるため、自分で記述したすべてのコンソール拡張は、完全修飾スケルトンURIを使用するように更新する必要があります。
WebLogic Server 10.0では、SNMPAgentMBean MBeanのMibDataRefreshInterval属性とServerStatusCheckIntervalFactor属性は非推奨となったため無視されます。
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.2以降のリリースでも使用できます。
JMXクライアントがWebLogic Server MBeanのみにアクセスし、weblogic.management.MBeanHomeのみを使用する場合は、アップグレードしなくてもWebLogic Server 9.2以降のインスタンスで実行できます。
WebLogic Server 8.1クラスを使用するJMXクライアントは、次のすべての条件に該当すれば、WebLogic Server 9.2以降のJMXエージェントと対話できます。
クライアントがWebLogic Server MBeanのみにアクセスします。
クライアントがweblogic.management.MBeanHomeのみを使用します(JDK MBeanServerインタフェースを使用しません)。
WebLogic Serverクラスが8.1 SP4で作成され、それに適切なパッチが適用されています。
JMXクライアントで、WebLogic Server MBeanとの対話またはカスタムMBeanの作成と使用に標準のJMX MBeanServerインタフェースが使用されている場合は、WebLogic Server 9.2以降のインスタンス用のJDK起動オプション-Djmx.serial.form=1.0を含める必要があります。
この起動オプションを含めると、JVMがオブジェクトをシリアライズするときにJMX 1.0のクラス記述が使用されるようになります。このオプションは、JMX 1.0クライアントが標準のJDKクラスを使用してJMX 1.2エージェントと通信する場合に必要です。
JMXクライアントがセキュリティ・プロバイダMBeanと対話する場合は、「セキュリティMBean」を参照してください。
JMXクライアントをWebLogic Server 12.1.1に準拠するよう更新することをお薦めします。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プログラミング・モデルを使用するよう更新することをお薦めします。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanに関する項を参照してください。
MBeanの階層構造に加えられた変更により、9.2より前の構成および管理スクリプト(WLST、wlconfig、weblogic.Admin、Antなど)が12.1.1で動作する保証はなくなりました。WebLogic Server 9.2以降の新しい機能を利用するようスクリプトを更新することをお薦めします。MBean階層における新しい機能と変更の詳細は、表A-4にリストされたドキュメントを参照してください。
表A-4 リリースごとのWebLogic Serverの新機能
| リリース | 次の新機能の説明を参照 |
|---|---|
|
9.2 |
WebLogic Server 9.2の新機能:
|
|
10.0 |
WebLogic Server 10.0の新機能:
|
|
10.3 |
WebLogic Serverの新機能 バージョン10.3:
|
|
10.3.1 |
Oracle WebLogic Serverの新機能 11gリリース1 (10.3.1):
|
|
10.3.2 |
Oracle WebLogic Serverの新機能 11gリリース1 (10.3.2):
|
|
10.3.3 |
Oracle WebLogic Serverの新機能 11gリリース1 (10.3.3):
|
|
10.3.4 |
Oracle WebLogic Serverの新機能 11gリリース1 (10.3.4):
|
|
12.1.1 |
Oracle WebLogic Serverの新機能 12cリリース1 (12.1.1)
|
アプリケーション・インフラストラクチャのアップグレードと非推奨となったスクリプト・ツールの詳細は、「ステップ1: アプリケーション・インフラストラクチャのアップグレード」を参照してください。
構成属性は、動的なものと動的でないものに分類されます。
動的な構成属性への変更は、アクティブ化するとただちに有効になり、その変更の影響を受けるサーバーまたはシステム・リソースを再起動する必要はありません。この種の変更がサーバーおよび実行時階層で有効になるのは、変更がアクティブ化されたときです。
動的でない構成属性への変更は、ただちには有効になりません。動的でない構成属性への変更を適用するには、サーバーまたはシステム・リソースを再起動する必要があります。
WebLogic Server 9.0から導入された変更管理プロセスにより、構成の変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、構成されているサーバーまたはシステム・リソースが動的でない属性の変更の影響を受ける場合、サーバーまたはシステム・リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更(動的な変更も含む)は有効になりません。この場合、システムの整合性状態を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお薦めします。
構成スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバーを再起動する必要があります。変更が動的でなく、サーバーの再起動が必要かどうかを判断するには:
変更をアクティブ化する前には、次を実行できます。
管理コンソールのチェンジ・センターに表示されている変更一覧を確認します。『Oracle WebLogic Serverの理解』の動的な変更および動的でない変更に関する項を参照してください。
isRestartRequiredまたはshowChangesのどちらかのWLSTコマンドを使用します。詳細は、WebLogic Scripting Toolのコマンド・リファレンスを参照してください。
変更をアクティブ化した後には、次を実行できます。
サーバー・ログで変更が動的でない変更として分類されているかどうかを確認します。
必要に応じて、変更されたオブジェクトに関連付けられているRestartRequired属性またはPendingRestartSystemResources属性の値を確認します。
どのセキュリティ属性が動的であるか動的でないかを確認するには、『Oracle WebLogic Serverの保護』のセキュリティ構成MBeanに関する項を参照してください。
詳細は、『Oracle WebLogic Serverドメイン構成の理解』の構成変更の管理に関する項を参照してください。
JDBCの構成を簡素化し、構成エラーが発生する可能性を低くするため、WebLogic Server 9.0からは、使用するJDBCリソースのタイプが少なくなっています。JDBC接続プールを構成してから、その接続プールを指し、JNDIツリーにバインドされるデータ・ソースまたはトランザクション・データ・ソースを構成するかわりに、接続プールを包含するデータ・ソースを構成できるようになりました。WebLogic Server 9.0で導入された簡素化されたJDBCリソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の簡素化されたJDBCリソース構成に関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config)を参照してください。
次の項で説明するように、WebLogicアップグレード・ウィザードは、JDBCデータ・ソース、接続プール、マルチ・プール、およびデータ・ソース・ファクトリをWebLogic Server 12.1.1仕様に自動的に変換します。
|
注意: アップグレードしたそれぞれのJDBCモジュールに内部プロパティ・セクションがあります。WebLogic Serverでは、下位互換性に対応するため、データ・ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBCデータ・ソース・ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。 |
WebLogic Server 9.0で非推奨になったJDBC機能、メソッド、インタフェース、およびMBeanの詳細は、『リリース・ノート』の非推奨になったJDBCの機能、メソッド、インタフェース、およびMBeanに関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_jdbc_features)を参照してください。
アップグレード・ウィザードは、従来のJDBCデータ・ソース/接続プールの組合せを2つのデータ・ソース・システム・リソース・モジュールに変換します(1つはデータ・ソース用、もう1つは接続プール用)。
既存のデータ・ソースまたはトランザクション・データ・ソースに置き換わるデータ・ソースは、データ・ソース・パラメータを定義し、その接続プールと関連属性を定義するもう1つのデータ・ソースを参照する
既存の接続プールに置き換わるデータ・ソースは、JDBCドライバ・パラメータ、接続プール・パラメータ、およびXAパラメータを定義する
|
注意: ドメインのアップグレードの1つのプロセスとして変換されるデータ・ソースのみが、その接続プールを定義するもう1つのデータ・ソースを参照することができます。それ以外のデータ・ソースは、それぞれ独自のデータベース接続プールを保有しています。 |
アップグレード時にアップグレード・ウィザードにより、データ・ソースのGlobalTransactionsProtocolパラメータが、変換されるデータ・ソースのタイプ(トランザクションまたは非トランザクション)と関連する接続プールで使用されるドライバのタイプに基づいて設定されます。これを表A-5に示します。
表A-5 グローバル・トランザクションのプロトコル・パラメータ設定
| 従来のデータ・ソース・タイプ | ドライバ・タイプ | 2フェーズ・コミットのエミュレーション | GlobalTransactionProtocol |
|---|---|---|---|
|
Txデータ・ソース |
XA |
N/A |
TwoPhaseCommit |
|
Txデータ・ソース |
非XA |
False |
|
|
Txデータ・ソース |
非XA |
True |
|
|
データ・ソース |
非XA |
N/A |
なし |
脚注 1 使用する環境によっては、トランザクション処理にEmulateTwoPhaseCommitトランザクション・プロトコルではなくLoggingLastResource(LLR)トランザクション・プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。
アップグレード・ウィザードは、マルチプールを、データ・ソース間のロード・バランシングまたはフェイルオーバーを実現するデータ・ソース・オブジェクトのもう1つのインスタンスであるマルチ・データ・ソースに変換します。
データ・ソース・ファクトリは、WebLogic Server 9.0より非推奨となっており、下位互換性の維持だけを目的として含まれています。データ・ソース・ファクトリの変換は不要です。
実行キューは、WebLogic Server 9.0の時点でデフォルトの方法ではないため、スレッド管理にはワーク・マネージャの概念を使用することをお薦めします。アプリケーション用のルールと制約を定義するには、ワーク・マネージャを定義して、それをWebLogicドメインに対してグローバルに適用するか、特定のアプリケーション・コンポーネントに対して限定的に適用します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。
WebLogic Server 8.1では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上させるために8.1で実行キューを使用していた場合は、アプリケーション・ドメインのアップグレード後にも実行キューを引続き使用できます。アップグレードしたアプリケーションでユーザー定義実行キューを引続き使用できるようにするために、use81-style-execute-queuesというフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と、実行キューの構成および監視に関する詳細は、Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのWebLogic 8.1スレッド・プール・モデルを有効にする方法に関する項を参照してください。
WebLogic Server 9.0からは、XMLのサポートが次のように変更されています。
デフォルトのXMLパーサーは、Sun Java 2 JDK付属のXMLパーサーになりました。以前のデフォルトXMLパーサー、Apache Xercesパーサー(weblogic.apache.xerces.*)は9.0より非推奨となりました。
デフォルトで使用されるXMLパーサーを管理コンソールで修正することができます。XMLパーサーの構成については、『Oracle WebLogic Server XMLのプログラミング』のWebLogic Serverバージョン8.1と9.0のデフォルト・パーサーの違いに関する項を参照してください。
WebLogic Server 9.0からは、Java Community Processの標準仕様であるStreaming API for XML (StAX)がサポートされています。これにより、XMLドキュメントを簡単に、直感的に解析および生成できます。また、StAXでは、9.0から非推奨となっているWebLogic XML Streaming APIよりも的確にXML解析を行うことができます。StAXの使用については、『Oracle WebLogic Server XMLのプログラミング』のStreaming API for XML (StAX)の使い方に関する項を参照してください。
所定の事前準備設定を行うことなしにsetAttributeメソッドとgetAttributeメソッドを使用してサーブレット内からXMLドキュメントを解析することができなくなりました。具体的には、9.0以降、weblogic.servlet.XMLParsingHelperと呼ばれるWebLogic Serverのサーブレット・フィルタ(デフォルトではすべてのWebLogic Serverインスタンスにデプロイされる)をWebアプリケーションの一部として構成する必要があります。詳細は、『Oracle WebLogic Server XMLのプログラミング』のサーブレットでのXMLドキュメントの解析に関する項を参照してください。
WebLogic Server 9.0から、XMLBean実装は内部BEAライブラリ(com.bea.xml)からApacheオープン・ソース・プロジェクト(org.apache.xmlbeans)に移動されています。
WebLogic Server 8.1のアプリケーションでXMLBeansを使用していた場合は、次の手順を実行する必要があります。
XMLBeansにより使用されているパッケージ名をcom.bea.xmlからorg.apache.xmlbeansに更新します。
XMLBeanスキーマを再コンパイルして、スキーマ・メタデータ・ファイル(.xsb)と生成されているコードを更新します。
9.0以降、XMLQuery (XQuery)実装は次の仕様に準拠しています。
「XQuery 1.0 and XPath 2.0 Data Model - W3C Working Draft 23 July 2004」(http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723)
「XQuery 1.0: An XML Query Language - W3C Working Draft 23 July 2004」(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)に準拠していました。この2002 XQuery実装は、9.0以降では非推奨となっています。
ほとんどの場合、9.0より前のバージョンのコードに含まれる簡単なXQueryおよびXPathは、10.0でも同じように動作します。XQueryおよびXPathの処理が意図したとおりの結果になるように、次のいずれかの方法で、XMLObject.selectPath()およびXMLObject.execQuery()のメソッド呼出しを必要に応じて確認または変更してください。
8.1と同様の動作を保証するには、既存のメソッド呼出しを変更し、新しい2004 XQueryエンジンではなく2002 XQueryエンジンを使用することを指定する新しいパラメータを含めるようにします。例:
import org.apache.xmlbeans.impl.store.Path;
XmlObject xo = ?
xo.selectPath(".//c", (new XmlOptions()).put(Path._forceXqr12002ForXpathXQuery));
|
注意: 2002 XQueryエンジンは、WebLogic Server 9.0以降では非推奨ですが、下位互換性のために残されています。このパラメータを指定する場合にのみ使用できます。指定しない場合は、2004 XQueryエンジンがデフォルトで使用されます。 |
2004 XQueryエンジンへの適合を保証するには、9.0より前のスクリプトを確認し、メソッド呼出しに渡されているXQuery文字列の構文またはセマンティクスに関して変更が必要になると考えられる点をすべて特定して、メソッドに適切な変更を加えます。
9.0から、XMLCursor.moveXML()の動作が変更されています。8.1では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0以降では、カーソルはフラグメントと共に移動します。
この項では、リリース9.0より変更されたWebLogic Server環境におけるデプロイメント記述子の使用方法について説明します。
デプロイメント記述子の検証は、9.0リリース以降のEJBGenツールとejbcツールでは、より厳密に行われるようになりました。たとえば、@ejbgen:relationでcmr-fieldが定義されている場合に、@ejbgen:cmr-fieldというタグの付いたメソッドがBeanクラスになければ、エラーが返されます。
|
注意: ejbcはWebLogic Server 9.0から非推奨となりました。かわりにappcを使用してください。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のappcリファレンスに関する項を参照してください。 |
9.0より前のバージョンのWebLogic Serverでは、次の構成ファイルからの抜粋が示すように、複数のモジュールを定義するアプリケーションは、META-INF\application.xmlデプロイメント記述子がアプリケーションの一部として定義されているかどうかに関係なく、正常にデプロイされます。
<Application Deployed="true" Name="SessionBeanLifeCycleBean"
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"/>
</Application>
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.
ドメインをアップグレードするとき、デプロイされたアプリケーションが適切なJava EEアプリケーション形式に準拠していることを確認してください。たとえば、必要に応じて、アプリケーションがMETA-INF\application.xmlデプロイメント記述子またはMETA-INF\weblogic-application.xmlデプロイメント記述子を定義していることを確認してください。
デプロイメント記述子の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。
アプリケーションが最新のJava EE仕様およびWebLogic Serverリリースの機能を活用できるよう、アプリケーションをWebLogic Serverの新リリースにアップグレードするときに、デプロイメント記述子をアップグレードすることを推奨します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の以前のリリースのJ2EEおよびWebLogic Serverのデプロイメント記述子のアップグレードに関する項を参照してください。
アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Server 9.0から非推奨となり、かわりにアプリケーションはアプリケーション・ライフサイクル・イベントに応答するようになりました。ドメイン・レベルのアプリケーション・スコープの起動クラスと停止クラスのかわりにライフサイクル・イベントを使用するようアプリケーション環境を更新することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のアプリケーション・ライフサイクル・イベントのプログラミングに関する項を参照してください。
表A-6に、非推奨またはサポート対象外となったリソース・アダプタの構成設定を示します。新機能および変更点については、『Oracle WebLogic Serverの新機能』を参照してください。
表A-6 非推奨またはサポート対象外となったリソース・アダプタの構成設定
| 要素 | WebLogic Server 9.0の時点... |
|---|---|
|
Link-Refメカニズム |
この要素は非推奨となっており、新しいJava EEライブラリ機能に置き換えられています。Java EEライブラリの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有J2EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。 Link-Refメカニズムは、J2CA 1.0仕様に準拠して開発されたリソース・アダプタの場合は、このリリースでもサポートされています。1.0リソース・アダプタでのLink-Refメカニズムの使用の詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』の「weblogic-ra.xmlファイルの構成」、(非推奨)Link-Refメカニズムの構成に関する項を参照してください。 |
<shrink-period-minutes> |
この要素は非推奨となっており、
|
<connection-maxidle-time> |
この要素は非推奨となっており、
|
<security-principal-map> |
この要素はサポートされなくなりました。セキュリティ・プリンシパル・マップは管理コンソールを使用して構成されます。 weblogic-ra.xmlファイルから |
<connection-cleanup-frequency> |
この要素はサポートされなくなり、デプロイメントにおいて無視されます。 |
<connection-duration-time> |
この要素はサポートされなくなり、デプロイメントにおいて無視されます。 |
WLECは、WebLogic Server 8.1で非推奨となりました。WLECユーザーは、『Oracle WebLogic Server WLECのためのWebLogic Tuxedo Connector移行ガイド』の説明に従って、アプリケーションをWebLogic Tuxedo Connectorに移行する必要があります。
