| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server 7.0 へのアップグレード > WebLogic Server 6.x からバージョン 7.0 へのアップグレード |
|
WebLogic Server 7.0 へのアップグレード
|
WebLogic Server 6.x からバージョン 7.0 へのアップグレード
WebLogic Server 6.x からバージョン 7.0 へのアップグレードは、最も簡単な状況では、WebLogic Server 起動コマンド スクリプトと環境設定を変更するだけで完了します。場合によっては、ドメイン ディレクトリの移動が必要になります。また非常にまれですが、アップグレード対象のサブシステムに固有の変更が必要になることがあります。
以下の節では、システムを WebLogic Server 6.x から WebLogic Server 7.0 にアップグレードするために必要な情報を示します。
Pet Store アプリケーションを WebLogic Server 6.1 から WebLogic Server 7.0 にアップグレードする方法、また、WebLogic 6.0 および 6.1 のサンプル サーバを WebLogic Server 7.0 にアップグレードする方法については、Pet Store アプリケーションおよびサンプル サーバのアップグレードを参照してください。
WebLogic Platform 7.0 (7.0.0.1) へアップグレードする方法については、『WebLogic Server FAQ 集』の「アップグレード」を参照してください。
注意: このマニュアル全体を通して、「アップグレード」という用語は WebLogic Server のより新しいバージョンへのアップグレードを指し、「移植」は、アプリケーションを WebLogic Server の以前のバージョンからより新しいバージョンに移動することを指します。
WebLogic Server コンフィグレーションのアップグレード : 主な手順
WebLogic Server 6.x から WebLogic Server 7.0 にアップグレードするには、次の手順に従います。
サーバのクラスタをアップグレードするには、それぞれのサーバについて上記の手順に従い、その後、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic クラスタのセットアップ」で説明されている手順に従います。RMI/T3 または RMI/IIOP を使用してアプリケーションを起動する場合、WebLogic Server 6.1 と 7.0 は相互運用が可能です。ただし、1 つのドメインの内部ではすべてのサーバが同じバージョンでなければなりません。
WebLogic Server ライセンス ファイルのアップグレードについては、『インストール ガイド』の「ライセンス アップグレードに際してのご注意」を参照してください。
以前のバージョンで WebLogic Server 起動スクリプトを使用していた場合は、WebLogic Server 7.0 で利用できるようにスクリプトを変更する必要があります。
ここでの説明に従って、起動スクリプトを修正します。起動スクリプトの修正方法についてのもう 1 つの例は、Pet Store アプリケーションおよびサンプル サーバのアップグレードを参照してください。
WebLogic Server 7.0 は、サーバのインストール時に JDK 1.3.1_02 の JVM をインストールします。サーバに付属する setenv.sh スクリプトはすべてこの JVM を指しています。動作確認された JVM についての最新情報は、「動作確認状況」ページで公開されています。
WebLogic Server 7.0 のディレクトリ構造について
WebLogic Server 7.0 のディレクトリ構造は、バージョン 6.x のものとは異なります。新しくなったディレクトリ構造の詳細については、『インストール ガイド』の「インストール後の作業の実行」の章の「WebLogic Server のディレクトリ構造について」を参照してください。
WebLogic Server 7.0 環境を使用して WebLogic Server 6.x ドメインを起動している場合、新しいディレクトリ構造が自動的に作成されます。ただし、WebLogic Server 6.x ドメインのディレクトリ構造を前提としているカスタム ツールまたはスクリプトがある場合、新しいディレクトリ構造に合わせて、それらのツールの相対パス設定を更新する必要があります。また同様に、スクリプトによって WebLogic Server 6.x 環境でドメインを作成するためのツールがある場合、そのスクリプトを変更する必要があります。スクリプトによる制御が可能なコンフィグレーション ウィザードを使用するのが最もよい方法です。
WebLogic Server 6.x から WebLogic Server 7.0 へのアプリケーションの移植
注意: このマニュアル全体を通して、作成される新しい WebLogic Server 7.0 ドメインのディレクトリを domain と表記します。
WebLogic 6.x アプリケーションを WebLogic Server 7.0 に移行するには、次の手順に従います。
すべての外部ファイルが相対パスを使用して定義されており、ドメイン ディレクトリ内またはそれよりも下の階層に位置している場合、以降の手順はスキップしてください。
ドメイン ディレクトリの外部の位置を指す相対パスを使用して外部ファイルが定義されている場合、新しい config ディレクトリを起点にしたディレクトリ構造を作成し直してから、関連付けられているファイルを新しいディレクトリにコピーします。外部ファイルが絶対パスを使用して定義されている場合、これらのファイルを WebLogic Server 7.0 デプロイメントで再利用するのが適切かどうかを判断します。
たとえば、ログ ファイルや永続性ストアは再利用できますが、Java コンパイラなどのユーティリティについては、最新バージョンを使用するための更新が必要な場合があります。更新が必要なファイルについては、次の手順に進む前に、WebLogic Server 6.x の Administration Console を使用して必要な属性を編集し、新しいファイルまたはユーティリティが使われるようにします。
注意: WebLogic Server 7.0 では、デプロイメント記述子にエラーのあるアプリケーションはデプロイされません。以前のバージョンの WebLogic Server では、デプロイメント記述子のエラーのあるアプリケーションもデプロイされていました。
WebLogic Server 7.0 は新しいセキュリティ アーキテクチャを備えています。個別の質問とその回答については、『WebLogic Security の紹介』を参照してください。
WebLogic Server 7.0 は、WebLogic Server の以前のバージョンからのアップグレードを行っているのか、それともバージョン 7.0 の新規インストールなのかを検出します。WebLogic Server 6.x からアップグレードしている場合、WebLogic Server 7.0 は互換性セキュリティで動作し、6.x のユーザおよびグループのコンフィグレーションを保持することができます。
ただし、6.x の主なセキュリティ機能には非推奨となったものもあり、WebLogic Server 7.0 ではセキュリティ機能が改良および拡張されているため、セキュリティ コンフィグレーションのアップグレードをお勧めします。以下の問題と手順のリストを参照してください。
注意: WebLogic Server 7.0 のサンプルと PetStore は、デフォルトのセキュリティ コンフィグレーションを使用するようにコンフィグレーションされています。WebLogic Server 7.0 のサンプルと PetStore を互換性セキュリティで実行することはできません。
互換性セキュリティでの WebLogic Server の起動
WebLogic Server の以前のリリースでは、ファイル レルムがデフォルトとしてコンフィグレーションされていました。そのため、config.xml ファイルにセキュリティ レルムが定義されていなくても、WebLogic Server はファイル レルムを使用して起動できました。ただし、WebLogic Server を互換性セキュリティで実行するには、config.xml ファイルでファイル レルムまたは代替セキュリティ レルムを定義している必要があります。定義されていない場合、サーバが起動しないことがあります。
WebLogic Server を互換性セキュリティで起動できない場合は、新しいドメイン フォルダに SerializedSystemini.dat をコピーしてから、次のいずれかの作業を行います。
<Security Name=mydomain Realm=mysecurity/>
<Realm Name=mysecurity FileRealm=myrealm/>
<FileRealm Name=myrealm/>
MBean の ACL は WebLogic Server 7.0 ではサポートされていません。WebLogic Server 7.0 で MBean を保護する方法については、『管理者ガイド』の「システム管理操作の保護」を参照してください。
互換性セキュリティから WebLogic Server 7.0 セキュリティへのアップグレード
WebLogic Server 7.0 の新しいセキュリティ機能を活用する場合、既存のセキュリティ レルムを WebLogic Server 7.0 のセキュリティ レルムにアップグレードする必要があります。アップグレードを行うには、WebLogic Server 7.0 のセキュリティ プロバイダに既存のユーザとグループの情報を取り込み、リソースのセキュリティ ポリシーを定義して ACL 反映させます。
WebLogic Server 6.x コンフィグレーションが正常に起動する過程で、デフォルトのセキュリティ レルムとして互換性レルムが作成されます。互換性レルムには 6.x のセキュリティ データがすべて含まれています。また、myrealm という名前の、デフォルトの WebLogic Server 7.0 セキュリティ レルムも作成されます。アップグレードするには、互換性レルムを myrealm に置き換える必要があります。WebLogic Server Administration Console で次の操作を行います。
WebLogic Server 7.0 ではセキュリティ レルムの有効範囲が変更されました。WebLogic Server 6.x では、セキュリティ レルムで認証および認可サービスを提供していました。ファイル レルムか、または Lightweight Data Access Protocol (LDAP)、Windows NT、UNIX、RDBMS レルムなどの代替レルムを選択しました。また、カスタム セキュリティ レルムを記述することもできました。
WebLogic Server 7.0 では、セキュリティ レルムはスコーピング (有効範囲の設定) メカニズムとして機能します。各レルムはコンフィグレーション済みのセキュリティ プロバイダ、ユーザ、グループ、ロール、およびセキュリティ ポリシーのセットから構成されます。セキュリティ レルム内の認証および認可プロバイダが、認証および認可サービスを提供します。
6.x のセキュリティ レルムを WebLogic Server 7.0 にアップグレードするには、以下のような方法があります。
互換性セキュリティの使い方については、互換性セキュリティでの WebLogic Server の起動を参照してください。
注意: レルム アダプタ認証プロバイダを、バージョン 7.0 のセキュリティ レルムの認証プロバイダとしてコンフィグレーションしている場合には、RDBMS レルムに格納されている ACL にアクセスできません。ロールおよびセキュリティ ポリシーを使用してアプリケーション リソースを保護する必要があります。
WebLogic Server 7.0 のセキュリティ レルムでレルム アダプタ認証プロバイダを使用するには、以下の手順に従います。
注意: ACL は WebLogic Server 7.0 にアップグレードされません。
WebLogic Server 7.0 では、guest ユーザはデフォルトでは提供されなくなりました。guest ユーザを使用するには、互換性セキュリティで実行するか、または使用しているセキュリティ レルムのデフォルトの認証プロバイダにユーザとして guest ユーザを定義する必要があります。ユーザを定義する方法については、『WebLogic リソースのセキュリティ』の「ユーザの作成」を参照してください。
WebLogic Server 6.x では、認証を受けていないユーザ (匿名ユーザ) がすべてゲスト ユーザ (guest) として認識され、ゲスト ユーザは WebLogic Server リソースへのアクセスを許可されていました。WebLogic Server 7.0 では、ゲスト ユーザと匿名ユーザが区別されます。WebLogic Server 6.x のときと同じようにゲスト ユーザを使用するには、デフォルトの認証プロバイダにゲスト ユーザを追加し、WebLogic Server の起動時に次のプロパティを設定します。
-Dweblogic.security.anonymousUserName=guest
このコマンドライン プロパティを指定しない場合、匿名ユーザの名前は <anonymous> になります。
WebLogic Server の以前のリリースでは、password.ini ファイルを使用して、WebLogic Server デプロイメントの管理 ID を特定することができました。password.ini ファイルは、WebLogic Server 7.0 ではサポートされなくなりました。このファイルは、暗号化された形式でユーザ名とパスワードを格納する boot.properties ファイルに置き換えられています。boot.properties ファイルの使用方法については、『管理者ガイド』の「起動 ID ファイルの作成」を参照してください。古い password.ini ファイルにはクリア テキストのパスワードが格納され、ユーザ名は格納されていないため、このファイルを直接アップグレードすることはありません。
この節では、SSL プロトコルのアップグレード方法についての情報を示します。信頼性のある CA キーストアの作成、プライベート キーのキーストアの作成、および、互換性セキュリティにおける CertAuthenticator の使用の手順を説明します。
WebLogic Server 7.0 では、デフォルトで、クライアントがサーバの信頼性のある認証局 (CA) のチェックを行います。このチェックは、WebLogic Server がクライアントとして機能している場合だけでなく、SSL プロトコルを介してクライアントおよびサーバを接続する場合には常に行われます。たとえば、クライアントが SSL プロトコルを使用して Apache HTTP サーバに接続している場合、クライアントはサーバから提示された信頼性のある認証局のチェックを実行します。クライアントがサーバの認証局に信頼性がないと判断した場合、認証局は拒否されます。以前のバージョンの WebLogic Server では、この信頼性検証は行われませんでした。
既存の WebLogic 6.x のクライアントで SSL プロトコルを介してサーバと通信するには、以下の変更を行います。
注意: このファイル フォーマットは、証明書ファイルではなく、キーストアです。信頼性のある認証局をキーストアにロードする必要があります。
キーストアに信頼性のある認証局を追加するには、コマンド プロンプトで以下のように入力します。
keytool -import -trustcacerts -alias <some alias name> -file <the
file that contains the trusted CA> -keystore <the trusted CA keystore>
-storepass <your trusted CA Keystore password>
WebLogic Server に付属の信頼性のある認証局は、WL_HOME/server/lib/cacerts ディレクトリに置かれています。以下のコマンドを使用して、WebLogic Server に付属の信頼性のある認証局をキーストアに追加します。
keytool -import -trustcacerts -alias <some alias name> -file <the
file that contains the trusted CA> -keystore WL_HOME/server/lib/cacerts
-storepass changeit
keytool の詳細については、Sun の Web サイト (http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/keytool.html) を参照してください。
クライアントについては、trustedCAKeyStore コマンドライン引数はデフォルトで JDK の jre/lib/security/cacerts キーストアになります。独自の CA を JDK の信頼性のある CA キーストアに追加し、コマンドライン引数は指定しないでおくことができます。 あるいは、信頼性のある独自の CA キーストアを作成し、そのキーストアを指すように引数を設定することができます。
双方向 SSL または相互認証については、クライアント側で上記の 2 つの手順を実行することに加えて、サーバ側で次のどちらかの手順を実行します。
信頼性のある CA 証明書を信頼性のある CA キーストアにロードしない場合、セキュア ポートの使用時に問題が生じる場合があります。
互換性セキュリティでの CertAuthenticator の使用
WebLogic Server 7.0 では、ユーザ名とパスワードの認証の前に、最初に CertAuthenticator が呼び出されます。この動作は WebLogic Server 6.x からの変更点です。従って、クライアントが双方向 SSL を使用し、セキュリティ資格としてとユーザ名とパスワードを提供していた場合、WebLogic Server 6.x 用に記述された CertAuthenticator を変更する必要があります。
変更の必要がある CertAuthenticator を使用すると、WebLogic Server 6.x では許可されても、WebLogic Server 7.0 ではアクセスが拒否されます。CertAuthenticator を変更するには、証明書が SSL 接続を作成するためだけに使用される場合、認識されない証明書またはすべての証明書に対して NULL を返すようにします。
WebLogic Server 7.0 では、X.509 ID アサーションはデフォルトで無効になっています。WebLogic Server 6.x の config.xml ファイルで CertAuthenticator を使用していた場合、互換性セキュリティを使用するときに、X.509 ID アサーションを手動でコンフィグレーションする必要があります。X.509 ID アサーションの有効化は、レルム アダプタ認証プロバイダに関するオプションを設定することによって行います。互換性セキュリティでの実行中に WebLogic Server Administration Console で次の手順を行います。
Certicom 暗号スイートに関して問題が発生した場合の対処については、『リリース ノート』の問題 073360 についての情報を参照してください。
WebLogic Tuxedo Connector のアップグレード
WebLogic Server 7.0 で WebLogic Tuxedo Connector を使用するためには、アプリケーションおよびコンフィグレーションに以下の変更を行う必要があります。
注意: WebLogic Tuxedo Connector のコンフィグレーション方法について、詳しくは「Administration Console を使用した WebLogic Tuxedo Connector のコンフィグレーション」を参照してください。
コネクタの以前のリリースでは、WebLogic Tuxedo Connector セッションの開始に WebLogic Server の起動クラスを、またセッションの終了に WebLogic Server の停止クラスを使用していました。WebLogic Server 7.0 では、WebLogic Tuxedo Connector は起動クラスまたは停止クラスを使用しません。WebLogic Tuxedo Connector セッションは WTCServer MBean を使用して管理されます。
WebLogic Server Tuxedo Connector セッションの開始と終了については、「サーバへの WTCServer の割り当て」を参照してください。
WebLogic Tuxedo Connector の XML コンフィグレーション ファイルの変換
WebLogic Tuxedo Connector はサービスとして実装され、独立した XML コンフィグレーション ファイルを使用しなくなりました。WTCMigrateCF ツールは、XML コンフィグレーション ファイルの情報を、アクティブな管理サーバの config.xml ファイルに移行します。WebLogic Tuxedo Connector の XML コンフィグレーション ファイルを変換するには、次の手順に従います。
java -Dweblogic.wtc.migrateDebug weblogic.wtc.gwt.WTCMigrateCF
-url URL -username USERNAME -password PASSWORD -infile CONFIGWTC
[-server SERVERNAME] [-domain DOMAIN] [-protocol PROTOCOL]
[-deploy]
移行が完了すると、移行ユーティリティは次のメッセージを表示します。
指定された XML コンフィグレーション ファイル内の情報が WTCServer MBean に移行され、手順 2 で指定したサーバの config.xml ファイルに取り込まれます。
WebLogic Tuxedo Connector でインバウンド RMI-IIOP を使用する方法については、「RMI/IIOP および CORBA を相互に運用するWebLogic Tuxedo Connector の使用」を参照してください。
インバウンド RMI-IIOP を使用する場合、WebLogic Tuxedo Connector のインスタンスを Tuxedo の CORBA アプリケーションに接続する参照オブジェクトを修正しなければなりません。Tuxedo の CORBA オブジェクトでは現在、サーバ名を使用してリモートの WebLogic Tuxedo Connector オブジェクトを参照しています。以前のリリースでは DOMAINID を使用していました。
コード リスト 1-1 ドメイン コンフィグレーション ファイル
*DM_RESOURCES
VERSION=U22
*DM_LOCAL_DOMAINS
TDOM1 GWGRP=SYS_GRP
TYPE=TDOMAIN
DOMAINID="TDOM1"
BLOCKTIME=20
MAXDATALEN=56
MAXRDOM=89
*DM_REMOTE_DOMAINS
TDOM2 TYPE=TDOMAIN
DOMAINID="TDOM2"
*DM_TDOMAIN
TDOM1 NWADDR="<Tuxedo ドメインのネットワーク アドレス:ポート>"
TDOM2 NWADDR="<WTC ドメインのネットワーク アドレス:ポート>"
*DM_REMOTE_SERVICES
"//servername"
servername は、使用している WebLogic Server の名前です。
詳細については、「ユーザ認証」を参照してください。
WebLogic Tuxedo Connector はアクセス制御リスト (ACL) を使用します。ACL は、サービスを実行できるリモート ドメインを制限することによって、ローカル ドメインの内部にあるローカル サービスへのアクセスを制限します。このパラメータの有効な値は次のとおりです。
WebLogic Tuxedo Connector の ACL ポリシーが LOCAL に設定されている場合、Tuxedo リモート ドメインの DOMAINID がローカル ユーザとして認証される必要があります。WebLogic Tuxedo Connector で DOMAINID がローカル ユーザとして認証されるようにするには、WebLogic Server コンソールを使用して次の手順を実行します。
WebLogic Tuxedo Connector の ACL ポリシーが GLOBAL の場合、ユーザのセキュリティ トークンが渡されます。管理上の変更は必要ありません。
WebLogic Tuxedo Connector のプロパティの設定
注意: WebLogic Tuxedo Connector のプロパティの設定方法については、「WebLogic Tuxedo Connector のプロパティの設定方法」を参照してください。
TraceLevel および PasswordKey は、現在では WebLogic Server のプロパティとなっています。
WebLogic Server ログ ファイルを使用して WebLogic Tuxedo Connector をモニタするには、WebLogic Server の TraceLevel プロパティを使用してトレース レベルを設定する必要があります。詳細については、「WebLogic Tuxedo Connector のモニタ」を参照してください。
tracelevel は、WebLogic Tuxedo Connector のトレース レベルを指定する 10,000 〜 100,000 の範囲の数値です。
weblogic.wtc.gwt.genpasswd ユーティリティを使用してパスワードを生成するには、WebLogic Server の PasswordKey プロパティを使用してパスワード キーを設定する必要があります。パスワードの生成方法については、「WTCPassword MBean のコンフィグレーション」を参照してください。
以下の節では、非推奨となった機能、アップグレード、および WebLogic Server 7.0 での重要な変更点についての有益な補足情報を示します。
注意: WebLogic Server 7.0 ではサンプル データベースとして PointBase 4.2 を使用しており、Cloudscape データベースは同梱されていません。
新しい ant タスクを開発している場合、server/lib/ant.jar ファイルをクラスパスに手動で追加する必要があります。
WebLogic Server 7.0 の組み込みトランスフォーマは、Apache Xalan 2.2 トランスフォーマをベースとしています。
Xalan API を直接使用することは非推奨になりました。それらの API を引き続き使用していて問題が発生する場合は、Java API for XML Processing (JAXP) を使用して XSLT を使用することをお勧めします。
Apache の Xalan コードは、Xerces と Xalan が連携できるように変更が行われています。その変更が含まれていないので、Apache から Xalan を使用すると問題が発生する場合があります。
一般には、JAXP を使用し、ベンダ固有のコードを SAX、DOM、および XSL 処理用に JAXP などの中立な API に移行するのが最適です。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME¥server¥ext¥xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。未修正版の Xerces パーサおよび Xalan トランスフォーマは、Apache Web サイトから直接ダウンロードしてください。
WebLogic Server 7.0 の組み込み XML パーサは、Apache Xerces 1.4.4 パーサをベースとしています。パーサは SAX および DOM インタフェースのバージョン 2 を実装しています。以前のバージョンに付属していた古いパーサを使用すると、旧式であることを示すメッセージが表示される場合があります。
WebLogic Server 7.0 には、WebLogic FastParser も付属します。 これは、WebLogic Web サービスに関連付けられた SOAP および WSDL ファイルなど、中小規模のドキュメントを処理するために特別に設計された高性能の XML パーサです。アプリケーションで中小規模 (要素数が 10,000 個程度まで) の XML ドキュメントを処理することがほとんどの場合、FastParser を使用するように WebLogic Server をコンフィグレーションします。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME¥server¥ext¥xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。未修正版の Xerces パーサおよび Xalan トランスフォーマは、Apache Web サイトから直接ダウンロードしてください。
WebLogic Server 6.1 および 7.0 には 2 種類の実行時モードがあります。2 つのモードは「開発」と「プロダクション」です。実行時モードは、WebLogic Server の起動時にコマンドライン パラメータを使用して選択します (-Dweblogic.ProductionModeEnabled=true | false)。このパラメータを設定しないと、サーバは開発モードで動作します。開発モードでは、サーバの動作は WebLogic Server 6.0 の場合と同じです。ただし、プロダクション モードの場合には自動デプロイメント機能が無効になります。applications ディレクトリ内のデプロイメント ユニットのうち、コンフィグレーション リポジトリ (config.xml) においてデプロイ対象として明示的に設定されていないものは自動的にはデプロイされません。WebLogic Server 6.1 および 7.0 では、デフォルト ドメイン (mydomain) および Pet Store の出荷時コンフィグレーションはプロダクション モードである点に注意してください。サンプルの出荷時コンフィグレーションは開発モードです。
WebLogic Server 7.0 では、新しい 2 フェーズ デプロイメント モデルを備えています。このデプロイメント モデルと、バージョン 7.0 のその他のデプロイメント機能の詳細については、「WebLogic Server デプロイメント」を参照してください。デフォルトでは、静的にコンフィグレーションされるアプリケーションは 6.x デプロイメント モデルを使用します。コンソールまたは新しいコマンドライン ユーティリティの weblogic.Deployer を使用して開始されるデプロイメントでは、新しい 2 フェーズ デプロイメント モデルが使用されます。
WebLogic Server 7.0 では、デプロイメント記述子にエラーのあるアプリケーションはデプロイされません。以前のバージョンの WebLogic Server では、デプロイメント記述子のエラーのあるアプリケーションもデプロイされていました。たとえば、6.x アプリケーションのデプロイメント記述子で参照記述スタンザが欠落していた場合、そのスタンザを追加するまでは 7.0 サーバにアプリケーションがデプロイされません。一般的なスタンザは次のようになります。
<ejb-reference-description>
<ejb-ref-name>ejb/acc/Acc</ejb-ref-name>
<jndi-name>estore/account</jndi-name>
</ejb-reference-description>
WebLogic Server 7.0 を使用する場合、6.x プロトコルを使用してコンソールからデプロイメントを行うことはできなくなりました。結果として、新しいデプロイメント API を使用しなければなりません。アプリケーションが以前に 6.x でデプロイされており、単にサーバを起動しているだけの場合、アプリケーションは 1 フェーズのデプロイメントによってデプロイされます。コマンドライン ユーティリティの weblogic.deploy および weblogic.refresh と、weblogic.management.tools.WebAppComponentRefreshTool はバージョン 7.0 では非推奨になっています。
非推奨になった MBean の属性および操作については、非推奨になった API と機能を参照してください。
開発モードのとき、管理サーバ上の applications ディレクトリ内のアプリケーションがステージングされるようになりました。バージョン 6.x ではステージングされませんでした。詳細については、『WebLogic Server アプリケーションの開発』の「2 フェーズ デプロイメント」の節の「アプリケーション ステージング」を参照してください。
EJB 2.0 仕様は、WebLogic Server 6.0 から WebLogic Server 7.0 までの間に大幅に、また WebLogic Server 6.1 から WebLogic Server 7.0 までの間にも若干変更されています。
ここでは重要な変更点をいくつか示します。WebLogic Server 6.0 から WebLogic Server 7.0 までの間に行われたすべての仕様変更を確認するには、http://java.sun.com/products/ejb/2.0.html から EJB 2.0 最終仕様を参照またはダウンロードしてください。
WebLogic Server 6.0 から WebLogic Server 6.1 までの間に行われた変更については、WebLogic Server バージョン 6.1 マニュアルの「WebLogic Server エンタープライズ JavaBean の概要」の「このリリースの拡張機能」を参照してください。WebLogic Server 6.x で動作した EJB 1.1 Bean は、通常はそのまま WebLogic Server 7.0 でも動作します。
EJB 2.0 Bean については、以下の変更が必要になる場合があります。
EJB 2.0 仕様の変更に由来する、その他の主な変更点は以下のとおりです。
アプリケーション デプロイメントのスコープ内でサーブレットを使用した際の問題への対処については、デプロイメントを参照してください。
weblogic.management.configuration.EJBComponentMBean の変更点
WebLogic Server 6.1 から WebLogic Server 7.0 にかけて、インタフェース weblogic.management.configuration.EJBComponentMBean が変更され、ComponentMBean および EJBContainerMBean の両方を拡張するようになりました。EJBComponentMBean を実装するすべてのメソッド (getVerboseEJBDeploymentEnabled など) は、WebLogic Server 6.0 から 7.0 に移行する際、EJBContainerMBean をサポートするように変更しなければなりません。
WebLogic Server 7.0 の max-beans-in-cache パラメータは、データベースの同時実行性を高めるためにキャッシュに格納される Bean の最大数を制御します。以前のバージョンの WebLogic Server では、max-beans-in-cache は無視され、キャッシュのサイズは無制限でした。このパラメータの値をより大きく調整しなければならない場合があります。
WebLogic Server 7.0 で実行される EJB QL クエリでは、すべてのパス式は完全修飾形式でなければなりません。これは WebLogic Server 6.x からの変更点です。WebLogic Server 7.0 上で 6.x EJB を使用していて、ejbc の実行時に ejbc エラーが発生する場合、ejb-jar.xml ファイル内の ejb-ql 要素、または weblogic-cmp-jar.xml ファイル内の weblogic-ql 要素のどちらかを修正する必要があります。次に例を示します。
SELECT address FROM CustomerBean AS c WHERE zip = ?1
SELECT c.address FROM CustomerBean AS c WHERE c.zip = ?1
WebLogic jCOM 6.1 から WebLogic jCOM 7.0 へのアップグレードについては、『WebLogic jCOM プログラマーズ ガイド』の「アップグレードの考慮事項」を参照してください。
JDBC 接続プールの最小の増加容量は、WebLogic Server 6.1 では 0 でしたが、バージョン 7.0 では 1 に変更されました。『WebLogic Server コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
JDBCConnectionPool MBean の PreparedStatementCacheSize および XAPreparedStatementCacheSize のデフォルト値は、WebLogic Server 6.1 では 0 でしたが、WebLogic Server 7.0SP2 以降のリリースでは 5 に増加されました。 Prepared Statement キャッシュとその制限の詳細については、『管理者ガイド』の「Prepared Statement キャッシュのパフォーマンスの向上」を参照してください。
WebLogic Server 7.0 は、JavaSoft の JMS 仕様バージョン 1.0.2 をサポートしています。
すべての WebLogic JMS 6.x アプリケーションは WebLogic JMS 7.0 でサポートされています。ただし、新しい高可用性 JMS の機能をアプリケーションで利用する場合は、既存の物理的な送り先 (キューおよびトピック) を、単一の分散送り先セットの一部としてコンフィグレーションする必要があります。JMS の分散送り先の使用方法については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
WebLogic JMS アプリケーションの移植の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」を参照してください。
WebLogic Server 6.x のすべてのパブリックな MBean および属性は、WebLogic Server 7.0 でサポートされています。ただし、内部的な MBean または属性を使用している場合には、移植時に問題が発生することがあります。
非推奨になった MBean の属性および操作については、非推奨になった API と機能を参照してください。
Jolt ユーザは、BEA WebLogic Server 7.0 を使用する Web に BEA Tuxedo サービスを対応させるために、Jolt Java Client 8.0.1 にアップグレードする必要があります。Jolt Java Client 8.0.1 は BEA Product Download Center から入手できます。BEA WebLogic Server 7.0 へのリンクを辿り、[ Modules for WebLogic Server] リストから [Jolt Java Client 8.0.1] を選択してください。
JSP 仕様の変更により、null のリクエスト属性は、空の文字列ではなく文字列「null」を返すようになりました。 WebLogic Server バージョン 6.1 からは、weblogic.xml に printNulls という新しいフラグが導入されています。このフラグはデフォルトで true になっており、デフォルトが「null」であることを意味しています。 このフラグを false に設定すると、「null」の式が文字列「null」ではなく空の文字列として出力されます。
weblogic.xml の printNulls 要素のコンフィグレーション例を次に示します。
<param-name>printNulls</param-name>
<param-value>false</param-value>
WebLogic Server 6.x を実行している管理対象サーバは、WebLogic Server 7.0 を実行している管理サーバを使用してそのコンフィグレーションおよび起動情報を取得できません。WebLogic Server 6.x のインストール ディレクトリにある running-managed-servers.xml ファイルを、WebLogic Server 7.0 のインストール ディレクトリにはコピーしないでください。
このドキュメントの以前のバージョンおよび他のサンプルのドキュメントに、Administration Server で MBeanHome インタフェースをルックアップする方法として weblogic.management.Admin.getInstance().getAdminMBeanHome() を使用するという誤った説明がありました。
weblogic.management.Admin クラスはパブリックではありません。 非パブリックなこのクラスを使用する代わりに、JNDI を使用して MBeanHome を取得します。 『WebLogic JMX Service プログラマーズ ガイド』の「例 : アクティブなドメインとサーバの判別」を参照してください。
WebLogic Server 6.x では、認証されないユーザ (匿名ユーザ) はすべて guest ユーザとして識別されました。また、guest ユーザは WebLogic リソースにアクセスできました。しかし、この機能はセキュリティ リスクを招くおそれがあったため修正されました。
新しいバージョンの WebLogic Server では、 guest ユーザはデフォルトではなくなりました。WebLogic Server 7.0 では、匿名ユーザに <anonymous> という名前が割り当てられ、guest ユーザと匿名ユーザが区別されます。
WebLogic Server 6.x と同じように guest ユーザを使用するには、以下のいずれかの方法で行います。
-Dweblogic.security.anonymousUserName=guest
警告: この引数は、既存の WebLogic Server ユーザが効率的にセキュリティ機能をアップグレードできるように追加されたものです。guest ユーザをプロダクション環境で使用する場合には十分な注意が必要です。アップグレードの詳細については、『WebLogic Server 7.0 へのアップグレード』の「セキュリティのアップグレード」を参照してください。
次の新しいクラスを使用するように、web.xml ファイルを更新してください。
weblogic.servlet.proxy.HttpClusterServlet
weblogic.servlet.internal.HttpClusterServlet
weblogic.servlet.proxy.HttpProxyServlet
weblogic.t3.srvr.HttpProxyServlet
アプリケーション デプロイメントのスコープ内でサーブレットを使用した際の問題への対処については、デプロイメントを参照してください。
WebLogic Server 6.0 では、ワーカ スレッドの数はサーバ MBean の ThreadPoolSize パラメータで指定しました。WebLogic Server 6.1 からは、ワーカ スレッドの数はサーバ MBean の ExecuteQueue で定義します。
WebLogic Server 7.0 ではこのパラメータの移植パスが提供されるので、それが config.xml で指定される場合、またはコマンドラインでクライアントまたはサーバに渡される場合 (-Dweblogic.ThreadPoolSize=<xx>)、ThreadPoolSize が自動的に ThreadCount 設定に移行されます。
<Server
Name="myserver"
ThreadPoolSize="23"
...
/Server>
<Server
Name="myserver"
... >
<ExecuteQueue
Name="default"
ThreadCount="23" />
/Server>
コンソールからスレッド数の値を変更するには、次の手順を行います。
weblogic.management.runtime.ServletRuntimeMBean.getName() API (WebLogic Server 6.0) は、WebLogic Server 6.1 および 7.0 で weblogic.management.runtime.ServletRuntimeMBean.getServletName() に変更されています。このインタフェースを使用する場合は、ソース コードを更新して再コンパイルする必要があります。
Java サーブレット仕様 2.3 では、転送時の認可がデフォルトでは行われなくなりました。セキュアなリソースへの転送時に認可を得るには、<check-auth-on-forward> を weblogic.xml ファイルに追加します。
サーブレットの Request オブジェクトと Response オブジェクトには新しい API があります。それらのオブジェクトのシリアライズ可能で軽量な一部の実装は、新しい API を実装しないとコンパイルされない可能性があります。新しいサーブレット 2.3 モデルを使用し、サーブレットの Request オブジェクトと Response オブジェクトの実装を置き換えることをお勧めします。WebLogic Server 6.0 でこれを行った場合は、これらのオブジェクトの文書化されていない内部実装に従っていたものと思われます。WebLogic Server 7.0 ではサーブレット 2.3 がサポートされているので、新しい ServletRequest/ResponseWrapper オブジェクトを利用できます。
Solaris での WebLogic Server クラスタ
Solaris 上の WebLogic Server クラスタにデプロイされた一部のアプリケーション (重い EJB アプリケーション) は、サーバ JVM ではなくクライアント JVM を使用することでパフォーマンスが向上します。このことは、負荷の大きな状況で特に顕著になります。
WebLogic Server のバージョン 6.1 から 7.0 の間に、Web サービスの実行時システムとアーキテクチャが変化したことにより、バージョン 6.1 で作成した Web サービスをバージョン 7.0 上で実行するにはアップグレードが必要です。
WebLogic Server 6.1 に組み込まれていた WebLogic Web サービス クライアント API は非推奨になり、この API を使用して 7.0 の Web サービスを起動することはできません。WebLogic Server 7.0 には、Java API for XML-based RPC (JAX-RPC) をベースとした新しいクライアント API が組み込まれています。
バージョン 6.1 の WebLogic Web サービスから 7.0 へのアップグレードについては、「WebLogic Web サービス 6.1 から 7.0へのアップグレード」を参照してください。
JAX-RPC を使用して WebLogic Web サービスを起動する例については、「Web サービスの呼び出し」を参照してください。
バージョン 6.1 と 7.0 のWeb サービスの違いについては、「WebLogic Web サービスの概要」を参照してください。
WebLogic Server 7.0 では、バージョン 6.x の config.xml ファイルから読み取られたコンフィグレーション情報が、WebLogic Server 7.0 の情報を取り込んで自動的に更新されます。サーバの複数回の起動の間にこれらの変更を保持するためには、config.xml ファイルを書き込み可能に設定する必要があります。ファイルを書き込み可能にするには、バージョン 6.x のコンフィグレーションから config.xml ファイルのバックアップ コピーを作成し、ファイル属性を変更します。
deploy
load
undeploy
LastModified
LoadError
isDeployed
これらの属性および操作に代わる要素については、WebLogic Server 7.0 javadoc の、ApplicationMBean インタフェースに関する説明箇所を参照してください。
WebLogic Enterprise Connectivity (WLEC) サンプルは削除されました。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
