WebLogic Server 8.1 へのアップグレード
|
 |
 |
|
WebLogic Server 7.0 からバージョン 8.1 へのアップグレードでは、ドメインを新しいディレクトリにコピーし、WebLogic Server 起動コマンド スクリプトと環境設定を変更する必要があります。
以下の節では、ドメインを WebLogic Server 7.0 から WebLogic Server 8.1 にアップグレードするために必要な情報を示します。
WebLogic Server 7.0 から WebLogic Server 8.1 へのドメインのアップグレード例については、「Pet Store アプリケーションの WebLogic Server 7.0 から WebLogic Server 8.1 へのアップグレード」を参照してください。
WebLogic Platform 8.1 にアップグレードする際の個々の質問とその回答については、『WebLogic Server FAQ 集』の「FAQ : アップグレード」を参照してください。
WebLogic Server ライセンス ファイルのアップグレードについては、『WebLogic Platform のインストール』の「WebLogic Platform ライセンス ファイルのインストールおよび更新」を参照してください。
WebLogic Server のセキュリティのアップグレードについては、「セキュリティ」を参照してください。
ドメイン ディレクトリの配置場所を、WebLogic Server インストール ディレクトリの外に指定することをお勧めします。WebLogic Server 7.0 以降のバージョンでは、WebLogic Server インストールと JDK にアクセスできる任意の場所にドメイン ディレクトリを配置できるようになりました。
ドメイン ディレクトリの場所を変更する場合は、新しいディレクトリ構造に関係するカスタム ツールやスクリプトも忘れずに更新してください。また同様に、スクリプトによってドメインを作成するためのツールを使用している場合は、そのスクリプトも変更してください。ドメインの作成には、スクリプト化が可能なコンフィグレーション ウィザードを使用することをお勧めします。
WebLogic Server 7.0 から 8.1 にアップグレードすると、WebLogic Server ドメインがアップグレードされます。WebLogic Server ドメインについては、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメインの概要」を参照してください。
ドメインのコンフィグレーション設定は、そのドメイン ディレクトリの config.xml ファイルに格納されます。config.xml には、ドメインの名前と、ドメイン内の各サーバ インスタンス、クラスタ、リソース、およびサービスのコンフィグレーション パラメータ設定が格納されます。
ドメイン ディレクトリには、ドメイン内の管理サーバと管理対象サーバの起動に使用できるサーバ起動スクリプト ファイルも格納されます。
ドメイン ディレクトリ構造には、mydomain や petstore など、ドメインと同じ名前を持つルート ディレクトリがあります。このディレクトリには以下を格納します。
config.xml) WebLogic Server ドメインの詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメイン」を参照してください。
複数のサーバ インスタンスを含むドメインも、単一サーバ ドメインと同じ方法でアップグレードします。nutshell を使用してアップグレードする場合は、WebLogic Server 7.0 がインストールされているマシンに 8.1 をインストールし、7.0 ドメインの内容を 8.1 ドメイン ディレクトリにコピーしてから、スクリプトや環境設定が新しい 8.1 のドメインおよびサーバ インスタンスを指すように変更します。
ドメインにクラスタが含まれており、WebLogic Server 8.1 の新しいクラスタ化機能を使用する場合は、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic クラスタの設定」に示した WebLogic Server 8.1 クラスタ コンフィグレーションのガイドラインを参照してください。
この節のアップグレード手順を実行する前に、アップグレードの対象となるドメインにあって 7.0 サーバ インスタンスが含まれているすべてのマシンに対して、WebLogic Server 8.1 をインストールする必要があります。 WebLogic Server 8.1 のインストール手順については、『WebLogic Platform のインストール』を参照してください。
アップグレードする WebLogic Server 7.0 ドメインにあるすべてのサーバ インスタンスを停止します。
サーバを停止することで、ドメインまたはそのアプリケーションへの最新の変更内容が確実に保持されます。「サーバの起動と停止 : クイック リファレンス」を参照してください。
8.1 ドメインを配置するための新しいディレクトリを作成します。
この新しい 8.1 ドメイン ディレクトリからみた外部リソースの相対的な位置が、7.0 ドメイン ディレクトリのときと異なる場合は、7.0 ドメイン ディレクトリの内容を 8.1 ドメイン ディレクトリに移動した後で、ドメイン内から外部リソースへの参照を変更する必要がありますので注意してください。
WebLogic Server 7.0 ドメイン ディレクトリの内容を新しい 8.1 ドメイン ディレクトリにコピーします。コピーする内容としては、サーバ起動スクリプト、コンフィグレーション設定などがあります。詳細については、「ドメイン ディレクトリの内容」を参照してください。
ドメインを WebLogic Server 8.1 にアップグレードした後は、WebLogic Server 7.0 に戻せないことがあるため、元のドメインのバックアップを作成しておいたほうがよいでしょう。
ドメインは WebLogic Server のインストール ディレクトリ外に配置することをお勧めします。
注意 :まだこの時点では、新しく作成したドメインのアプリケーション パスは、7.0 ドメインにデプロイされていたアプリケーションを指しています。ドメイン変換が完了するまでは、どちらのドメインのサーバ インスタンスも起動しないようにしてください。複数バージョンの WebLogic Server の下で、同じアプリケーションをデプロイするサーバ インスタンスを同時に実行すると、問題の発生する危険性が高まります。
新しいドメイン ディレクトリ内の .internal および .wlnotdelete ディレクトリの内容をすべて削除します。これらのディレクトリにはバージョンに固有として生成された設定が含まれることがあるため、8.1 ドメインで問題が発生する原因になります。
これらのディレクトリの場所は、ドメイン コンフィグレーションによって異なります。Petstore のアップグレード例 (「Pet Store アプリケーションの WebLogic Server 7.0 から WebLogic Server 8.1 へのアップグレード」を参照) では、これらのディレクトリは C:\petstorefrom70to81\server\config\petstore\petstoreServer\.internal および C:\petstorefrom70to81\server\config\petstore\petstoreServer\.internal\.wlnotdelete に配置されています。
WebLogic Server 7.0 サーバ インスタンスではなく 8.1 サーバ インスタンスを起動するように、新しいドメイン ディレクトリのサーバ起動スクリプトを変更します。この変更は、アップグレードしたドメイン内のすべての管理サーバおよび管理対象サーバに対して実施します。 新しい WebLogic Server ドメインに作成されるデフォルトの起動スクリプトの名前は、管理サーバの場合は startWebLogic.cmd (または .sh)、管理対象サーバの場合は startManagedWebLogic.cmd (または .sh) になります。
7.0 および 8.1 ドメインのサーバ起動スクリプトは、WL_HOME\server\bin ディレクトリにあるサーバ起動スクリプト startWLS.cmd を参照します (WL_HOME は WebLogic Server のインストール ディレクトリ)。
WebLogic Server 7.0 の WL_HOME70\server\bin ディレクトリ内の startWLS.cmd スクリプトを呼び出すサーバ起動スクリプトを編集して、WebLogic Server 8.1 の WL_HOME81\server\bin ディレクトリ内の startWLS.cmd スクリプトが呼び出されるようにします。
サーバ起動スクリプトによっては、そのプロパティの多くの設定内容を変更することが必要になります。「起動スクリプトの修正」を参照してください。
アプリケーションを WebLogic Server 8.1 にアップグレードします。
この作業では、アプリケーションのデプロイメント記述子ファイルとドメイン コンフィグレーション ファイル config.xml の編集が必要になる場合もあります。
8.1 ドメインからみた外部ファイルの相対的な位置が 7.0 ドメインと異なる場合は、アプリケーションを新しい 8.1 ドメインに移動した際に外部ファイルへの参照が正しくなくなっているおそれがあります。デプロイメント記述子ファイルおよび config.xml は、新しいドメイン ディレクトリに合わせて、外部ファイル (ログ ファイル、ファイル ベースのリポジトリ、Java コンパイラなど) を正しく参照している必要があります。
たとえば、Java コンパイラを最新バージョンに更新するには、WebLogic Server 8.1 Administration Console を使用して、該当する属性をユーティリティの新しいバージョン用に更新します。たとえば、Administration Console で Java コンパイラを変更するには、左ペインでサーバを選択してから右ペインで [コンフィグレーション｜全般] を選択し、[Java コンパイラ] フィールドの値を変更します。WebLogic Server 8.1 を使用してアプリケーションを再コンパイルする予定がある場合は、ビルド時に JDK 1.4 を参照します。詳細については、「8.1 でコンパイルする場合の JDK 1.4 の参照」を参照してください。
WebLogic Server 8.1 管理サーバと管理対象サーバを起動します。WebLogic Server 8.1 を起動する方法の詳細については、「サーバの起動と停止 : クイック リファレンス」を参照してください。
注意 :WebLogic Server 8.1 では、7.0 の config.xml ファイルから読み取られたコンフィグレーション情報が、WebLogic Server 8.1 の情報として自動的に取り込まれて更新されます。サーバを複数回、起動する間にもこうした変更を保持するためには、config.xml ファイルを書き込み可能に設定する必要があります。config.xml を読み込み専用にした場合は、書き込みを可能にするため、そのファイル プロパティにアクセスして属性を変更します。たとえば Windows の場合は、Windows エクスプローラでファイルを右クリックして [プロパティ] を選択し、[読み取り専用] 属性のチェックをはずします。
アプリケーションのコンフィグレーションとデプロイについては、『デプロイメント』を参照してください。
7.0 起動スクリプトを 8.1 に修正する具体例については、「Pet Store アプリケーションの WebLogic Server 7.0 から WebLogic Server 8.1 へのアップグレード」を参照してください。
WebLogic Server 7.0 の起動スクリプトを WebLogic Server 8.1 で利用できるように変更する一般的な手順を以下に示します。
startWLS.cmd (または .sh) スクリプトを指している WebLogic 7.0 起動スクリプトを WebLogic Server 8.1 startWLS.cmd (または .sh) スクリプトを指すように編集します。WebLogic Server 7.0 ドメインの管理サーバおよび管理対象サーバ用に WebLogic Server 7.0 ドメイン コンフィグレーション ウィザードによって生成されたスクリプトに基づく起動スクリプトも含め、すべての WebLogic 7.0 サーバ起動スクリプトを 8.1 サーバ起動スクリプトに変更します。
これらのスクリプトも WL_HOME70\server\bin\startWLS.cmd (または .sh) にある WebLogic Server 7.0 スクリプトを指しているので、新しい WebLogic Server 8.1 スクリプトを指すように編集します。
call "WL_HOME70\server\bin\startWLS.cmd"
call "WL_HOME81\server\bin\startWLS.cmd"
起動スクリプトの内容によっては、これ以降の手順で説明する設定などを追加で変更しなければならない場合があります。
WebLogic Server 8.1 で使用する JDK を指すようにします。次に例を示します。
setJAVA_HOME=WL_HOME\jdk131_03
setJAVA_HOME=WL_HOME\jdk141
JDK 1.4.1 についてのエラー メッセージが表示された場合は、「Java 2 Platform, Standard Edition Version 1.4.0 Compatibility with Previous Releases」を参照してください。
bea.home プロパティを修正して、WebLogic Server 8.1 の license.bea ファイルが置かれた BEA ホーム ディレクトリを指すようにします。たとえば、次のように指定します。if not exist lib\weblogic.jar goto wrongplace
このとき、lib\weblogic.jar がスクリプトの場所から見て正しくない場合は、weblogic.jar の相対位置を指すように変更するか、またはこの行を削除します。
WebLogic Server 8.1 は、サーバのインストール時に JDK 1.4.1 の JVM をインストールします。サーバに付属する setenv.cmd および .sh スクリプトはすべてこの JVM を指しています。動作確認された JVM についての最新情報は、『サポート対象のコンフィグレーション』ページで公開されています。
この節では、Sun の Pet Store アプリケーションを WebLogic Server 7.0 から 8.1 にアップグレードする手順を、順を追って説明します。ここで使用するバージョンの Pet Store は、WebLogic Server 7.0 に含まれています。
以下の手順を実行する前に、WebLogic Server 7.0 と 8.1 が同じマシンにインストールされていることを確認してください。
C:\petstorefrom70to81 にあります。このドメインは、WebLogic Server 8.1 のインストール ディレクトリの外に作成する必要があります。 Path="WL_HOME/samples/server/stage/petstore/petstore.ear" TwoPhase="true">
Path="c:/petstorefrom70to81/server/stage/petstore/petstore.ear" TwoPhase="true">
petstoreadmin.ear、opc.ear、supplier.ear、および tour.war についても同様に、WebLogic Server 7.1 の WL_HOME パスを c:\petstorefrom70to81 パスで置き換えます。
XAConnectionFactoryEnabled="true" を "Topic" JMSConnectionFactory コンフィグレーションに追加します。JTA トランザクションに自動的に登録されます。次の行を置き換えます。<JMSConnectionFactory JNDIName="jms/TopicConnectionFactory" Name="Topic" Targets="petstoreServer" />
<JMSConnectionFactory JNDIName="jms/TopicConnectionFactory"
Name="Topic" Targets="petstoreServer" XAConnectionFactoryEnabled="true" />
XAServerEnabled 属性を XAConnectionFactoryEnabled に置き換えます。次の行を置き換えます。<JMSConnectionFactory JNDIName="jms/QueueConnectionFactory" Name="Queue" Targets="petstoreServer" XAServerEnabled="true" />
%JAVA_HOME% エイリアスを、WebLogic Server 7.0 インストールで使用した JDK から、WebLogic Server 8.1 インストールで使用する JDK に変更します。次に例を示します。 set JAVA_HOME=WL_HOME\jdk131_03
%SAMPLES_HOME% エイリアスを、WebLogic Server 7.0 の \samples ディレクトリから、WebLogic Server 8.1 の \samples ディレクトリに変更します。次に例を示します。set SAMPLES_HOME=WL_HOME\samples
call "C:\bea70sp1\weblogic700\server\bin\startWLS.cmd"
-Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME\server\lib\cacerts
この節では、WebLogic Server 7.0 から 8.1 にアップグレードする際に留意する必要のあるその他の事項について説明します。
WebLogic Server 8.1 の組み込みトランスフォーマは、Apache Xalan 2.2 トランスフォーマをベースとしています。
Xalan API を直接使用することは非推奨になりました。それらの API を使用して問題が発生する場合は、Java API for XML Processing (JAXP) を利用して XSLT を使用してください。
WebLogic Server の組み込みトランスフォーマには、Xerces と Xalan が連携できるように変更された Apache の Xalan コードが反映されています。その変更が含まれていないため、Apache から Xalan を使用すると問題が発生する場合があります。
一般には、JAXP を使用し、ベンダ固有のコードを SAX、DOM、および XSL 処理用に JAXP などの中立な API に移行するのが最適です。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME\server\ext\xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。
WebLogic Server 8.1 の Xerces XML パーサは WebLogic Server 7.0 のものより厳密になっており、WebLogic Server 7.0 パーサでは受け付けられた不正な XML の解析が拒否されることがあります。
WebLogic Server 8.1 の組み込み XML パーサは、Apache Xerces 1.4.4 パーサをベースとしています。このパーサは SAX および DOM インタフェースのバージョン 2 を実装しています。以前のバージョンのパーサでは、非推奨であることを示すメッセージが表示されることがあります。
WebLogic Server 8.1 には、WebLogic FastParser も付属します。これは、WebLogic Web サービスに関連付けられた SOAP および WSDL ファイルなど、中小規模のドキュメントを処理するために特別に設計された高性能の XML パーサです。アプリケーションで中小規模 (要素数が 10,000 個程度まで) の XML ドキュメントを処理することがほとんどの場合、FastParser を使用するように WebLogic Server をコンフィグレーションします。詳細については、「WebLogic Server XML の管理」を参照してください。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME\server\ext\xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。
以下の節では、WebLogic Server 8.1 でのリソース アダプタの機能の変更点について説明します。
通常、クライアントが複数のリソース アダプタ接続で処理を実行し、グローバル トランザクションまたは XA トランザクションに参加するには、それに関与するリソース アダプタが XATransaction をサポートしている必要があります。しかし、グローバルまたは XA トランザクションには、ローカル トランザクションのみをサポートするリソース アダプタも関与する可能性があります。これは、これらのリソース アダプタがトランザクション マネージャからの 2 フェーズ コミット メッセージを受け取れないためです。
WebLogic Server 8.1 では、ローカル トランザクション対応リソース アダプタ接続がグローバル トランザクションで検出された場合、最初に、トランザクションに関与している XAResource に対してトランザクション マネージャから準備メッセージが発行されます。次に、すべての XAResource の準備が問題なく終了したら、ローカル トランザクション対応リソース アダプタで処理が実行されます。処理が成功した場合、グローバル トランザクションはコミットされます。処理が失敗した場合、グローバル トランザクションはロールバックされます。この方法によって、XA リソースでコミットが終了した後に、ローカル トランザクション対応リソース アダプタでコミットが失敗することがなくなります。
注意 : この最適化によって、ローカル トランザクション対応リソース アダプタが複数ある場合を除いて、複数の XAResource がグローバル トランザクションに参加可能になりました。複数のローカル トランザクション対応リソース アダプタをグローバルまたは XA トランザクションに参加させると、例外が発生し失敗します。
WebLogic Server 8.1 より前は、グローバルまたは XA トランザクションに関与できるローカル トランザクション対応リソース アダプタの数に制限はありませんでした。また、ローカル トランザクション対応リソース アダプタ特有の準備とコミットの順序は、今回の WebLogic Server 8.1 のように制御されていませんでした。これまでは、一部の XA トランザクション リソース アダプタでコミットが正常に終了した後に、ローカル トランザクション対応リソース アダプタでのコミットの呼び出しが失敗するおそれがありました。その場合、グローバルまたは XA トランザクションで、コミットされたリソースとロールバックされたリソースが混在するという問題が生じました。この最適化によって、従来生じたこの問題が解決されました。
クライアントがアプリケーションを使用しているかコンテナ管理によるセキュリティを使用しているかを示すメッセージが、サーバのログに記録されなくなりました。
WebLogic Server 8.1 では、各リソース アダプタは専用のクラスローダを持ち、それを使用して Web アプリケーションと同じ方法で各自のクラスをロードします。この変更によって、Web アプリケーションや、アプリケーション アーカイブ (.ear ファイル) にリソース アダプタとともにパッケージ化された EJB のようなコンポーネントには、リソース アダプタのクラスが見えなくなります。これらを可視にする必要がある場合は、リソース アダプタのクラスを APP-INF/classes ディレクトリに配置するか、または JAR ファイルにパッケージ化してアプリケーション アーカイブの APP-INF/lib ディレクトリに配置してください。
以前のバージョンとは違い、WebLogic Server 8.1 では、デプロイメント記述子にエラーのあるアプリケーションはデプロイされません。たとえば、WebLogic Server 7.0 アプリケーションのデプロイメント記述子で参照記述スタンザが欠落していた場合、そのスタンザを追加するまでは WebLogic Server 8.1 にアプリケーションがデプロイされません。一般的なスタンザは次のようになります。
<ejb-reference-description>
<ejb-ref-name>ejb/acc/Acc</ejb-ref-name>
<jndi-name>estore/account</jndi-name>
</ejb-reference-description>
WebLogic jCOM 6.1 から WebLogic jCOM 8.1 へのアップグレードについては、『WebLogic jCOM プログラマーズ ガイド』の「アップグレードに関する考慮事項」を参照してください。
この節では、WebLogic Server 8.1 での JDBC 関連の変更事項について概説します。
これまでに非推奨となっていた以下のインタフェースが削除されました。
WebLogic Server 8.1 では、weblogic.jdbc.pool.Driver クラス以外の weblogic.jdbc.pool クラスが削除されました。これは、JDBC ドライバによる JDBC 拡張機能をサポートするための内部的な変更と、これらのクラスとの互換性がないためです。
これらのクラスを使用しているアプリケーションを WebLogic Server 8.1 に移行するには、ベンダ固有の JDBC ドライバ クラスを使用するようにアプリケーションを修正する必要があります。たとえば、アプリケーションで weblogic.jdbc.pool.CallableStatement クラスを使用している場合であれば、oracle.jdbc.OracleCallableStatement などの JDBC ドライバからのクラスを使用するように変更します。
weblogic.jdbc.pool.CallableStatement cStat = (weblogic.jdbc.pool.CallableStatement)connection.prepareCall(call);
oracle.jdbc.OracleCallableStatement cStat = (oracle.jdbc.OracleCallableStatement)connection.prepareCall(call);
WebLogic Server 8.1 では、以下の JDBC ドライバが削除されました。
WebLogic Server 8.1 クライアントを古いバージョンのサーバと相互運用する (データ ソースにアクセスするなど) ときは、Oracle JDBC 拡張機能は使用できません。
WebLogic Server 8.1 より前のリリースでは、XA JDBC 接続プールと非 XA JDBC 接続プール用に独立した Statement キャッシュを実装していました。WebLogic Server 8.1 では、1 つの Statement キャッシュで XA および非 XA の両方の接続プールに対応します。JDBCConnectionPoolMBean にある、Statement キャッシュをコンフィグレーションするための接続プール属性は非推奨になりました。
バージョン 8.1 では、MBean 属性の優先順位が強制的に次のようになります。
たとえば、JDBC 接続プールの PreparedStatementCacheSize が 5 に、StatementCacheSize が 10 に設定されている場合、接続プール内の各接続に対応する実際の Statement キャッシュのサイズは 5 になります。PreparedStatementCacheSize が StatementCacheSize よりも優先されるためです。
PreparedStatementCacheSize を 0 に設定することで、アプリケーションにより文のキャッシングを無効化することはできません。XAPreparedStatementCacheSize の値は無視されます。代わりに PreparedStatementCacheSize を使用してキャッシュ サイズを割り当ててください。XaParamsMBean.PreparedStatementCacheSize のアプリケーション固有の値は、キャッシュのコンフィグレーション時には無視されます。 その代わりとして、PreparedStatementMBean.CacheSize が使用されます。PreparedStatementMBean.CacheSize を 0 に設定します。詳細については、「WebLogic JDBC のコンフィグレーションと使い方」の「接続プールの Statement キャッシュのコンフィグレーションと管理」を参照してください。
この節では、JDK をアップグレードするときに発生するおそれのある問題について説明します。
1.3.1_09 より前の JDK で許容されていた不正なコードが、JDK 1.3.1_09 以降ではエラーになるようになりました。このエラーは、Introspector API に関係する JSP およびすべての Bean で発生します。特に、プロパティのセッターとゲッターの型が異なると、JDK 1.3.1_09 以降への移行後に次のような起動エラーが発生します。
Error in using tag library uri='/WEB-INF/tlds/taglib.tld' prefix='j2ee': There is no setter method for property 'numItems', for Tag class 'com.sun.j2ee.blueprints.petstore.taglib.list.SearchListTag' probably occurred due to an error in /template.jsp line 8: <%@ taglib uri="/WEB-INF/tlds/taglib.tld" prefix="j2ee" %>
型の一致に関する Java Bean 仕様にクラスが準拠していないと、違反しているプロパティを読み書きするためのメソッドが java.beans.Introspector API から返されなくなります。こうしたエラーが発生しないようにするには、クラス内のセッターとゲッターの型を一致させます。セッターが整数であれば、ゲッターも整数にする必要があります。文字列にすることはできません。
たとえば、次の例のように有効なセッターとゲッターを指定すると、Introspection API から有効な read および write メソッドが返されます。
private String foo;
public void setFoo(String f) {
foo = f;
}
public String getFoo() {
return foo;
}
次に、Java Bean 仕様に準拠していないコード例を示します。
private int foo; // foo が int であることに注意
public void setFoo(String f) {
foo = Integer.parseInt(f);
}
public int getFoo() {
return foo;
}
2 つめの例では、セッターとゲッターの型が一致しておらず、JDK 1.3.1_09 以降では Java Bean 仕様に厳密に準拠しているためにエラーが発生します。 */
WebLogic Server 8.1 のアプリケーションをコンパイルする場合は、以前の JDK ではなく JDK 1.4 を参照して、以降のビルドを実行することをお勧めします。
API など、JDK 1.4 に追加されたものの中には、WebLogic Server 8.1 バージョンの weblogic.jar で削除されたものもあります。こうした API などは、クラスパスに以前のバージョンの weblogic.jar ではなく 8.1 の weblogic.jar を使用してアプリケーションをコンパイルした後は、WebLogic Server 8.1 のアプリケーションでは使用できなくなります。
たとえば JAXP は、以前のバージョンの weblogic.jar には入っていましたが、WebLogic Server 8.1 の weblogic.jar には入っていません。JAXP は JDK 1.3 には入っていないので、WebLogic Server 7.0 のアプリケーションで JAXP を使用していて、コンパイルに 7.0 の weblogic.jar ではなく 8.1 の weblogic.jar を使用した場合は、JDK 1.4 を使用してクラスをビルドしてください。
JDK 1.4 に対する他の WebLogic Server 8.1 の依存関係には、JAAS パッケージと Principal Authenticator オブジェクトが入っています。
JMS コンフィグレーションのチェックが、WebLogic Server 8.1 ではリリース 7.0 よりも厳密になりました。特に、JMS 送り先および接続ファクトリの指定に関しては注意が必要です。リリース 7.0 では、以下のコンフィグレーションが可能でした。
リリース 8.1 では、これらの場合に、同じ JNDI 名を割り当てることができなくなりました。そのため、これらの状況に該当するレプリケートされた JNDI 名を持つリリース 7.0 のコンフィグレーションは、リリース 8.1 にアップグレード後、起動に失敗するおそれがあります。
ドメインを WebLogic Server 8.1 にアップグレードする際には、JVM を JRockit にアップグレードすることを検討してください。WebLogic JRockit は、Intel アーキテクチャ上で動作する Windows および Linux で実行されるサーバサイド アプリケーション用に設計された JVM です。サーバサイド アプリケーションでは、他の仮想ホストに比べて、JRockit には次のようなメリットがあります。
JRockit プラットフォームとユーザ情報については、適切なバージョンの JRockit『ユーザーズ ガイド』を参照してください。
WebLogic Server ドメインを JRockit JVM にアップグレードするには次の手順に従います。
@rem Set user-defined variables.
set JAVA_HOME=WL_HOME\jdk131
WL_HOME は、WebLogic Server 7.0 のインストール ディレクトリです。これを次のように変更します。
@rem Set user-defined variables.
set JAVA_HOME=WL_HOME\jrockit81_141_02
JavaCompiler="WL_HOME\jdk131\bin\javac"
WL_HOME は、WebLogic Server 7.0 のインストール ディレクトリです。これを次のように変更します。
JavaCompiler=WL_HOME\jrockit81_141_02\bin\javac"
echo on "%JAVA_HOME%\bin\java" -hotspot .... weblogic.Server
StartupClassMbean のロード順メソッドの動作が、バージョン 7.0 (サービス パック 1) とバージョン 8.1 の間で変更されました。
バージョン 7.0 (サービス パック 1) では、LoadBeforeAppDeployments を true に設定すると、データソースが作成された後でアプリケーションがアクティブ化される前に、起動クラスが呼び出されました。8.1 で同じロード順を実現するには、LoadBeforeAppActivation を true に設定します。
LoadBeforeAppDeployments はバージョン 8.1 にもありますが、その動作は 7.0 (サービス パック 1) とは異なっています。7.0 (サービス パック 2) 以降では、起動クラスのロードおよび実行をサーバが JMS および JDBC サービスをアクティブ化する前に行うかアプリケーションと EJB をデプロイする前に行うかを、LoadBeforeAppDeployments で判別します。
WebLogic Server 8.1 におけるこうしたメソッドの詳細については、../javadocs/weblogic/management/configuration/StartupClassMBean.html を参照してください。
WebLogic 8.1 ではネットワーク チャネルの機能が拡大され、WebLogic Server 7.0 でネットワーク チャネルとネットワーク アクセス ポイントの両方で行っていた機能を網羅するまでに拡張されています。7.0 のドメインをアップグレードして WebLogic Server 8.1 で起動した際に、ネットワーク チャネルに関するエラー メッセージが表示される場合には、『WebLogic Server のコンフィグレーションと管理』の「チャネルのコンフィグレーション」で説明されているようにネットワーク チャネルを再度コンフィグレーションします。
NetworkChannelMbean の使用は、NetworkAccessPointMBean が使われるようになって非推奨になっています。
以前のリリースでは、プール接続はタイムアウトになるまでに、5 秒間待機しました。JTS/JTA 接続では、タイムアウトまでに 10 秒間待機しました。RMI Datasource 接続は非ブロッキング接続でした。WebLogic Server 8.1 リソースでは、すべての接続が、タイムアウトになるまでに最大 10 秒間ブロックされます。
RMI/T3 または RMI/IIOP を使用してアプリケーションを起動する場合、WebLogic Server 7.0 と 8.1 は相互運用が可能です。ただし、1 つのドメインの内部ではすべてのサーバが同じバージョンでなければなりません。
新しい Prepared Statement キャッシュ アルゴリズムが導入されました。このアルゴリズムでは、最も長い時間未使用の文がキャッシュから削除されます。元のアルゴリズムでは、固定数の文がキャッシュに保存されました (最初の n、n はコンフィグレーションされたキャッシュのサイズ)。以前のキャッシュ アルゴリズムの動作を使用する場合は、「FIXED」アルゴリズムを使用するように接続プールをコンフィグレーションできます。
WebLogic Server 8.1 では、実行キューのデフォルト名が変更されました。実行キューを指定するコンフィグレーションをアップグレードする場合、新しい実行キューの名前として、デフォルトのキュー名が自動的に付けられます。
以下の節では、WebLogic Server 8.1 のセキュリティに関する一般的な変更について説明します。
バージョン 7.0 サービス パック 2 より前の WebLogic Server では、証明書チェーンの各証明書が認証局によって発行されたことを保証しませんでした。この問題は、サービス パック 2 で解決されました。
8.1 にアップグレードする前は SSL 通信が正常に動作していて、アップグレード後に予期しないエラーが発生するようになった場合は、証明書チェーンが検証に失敗したことが原因で問題が発生している可能性があります。
証明書に関する問題を解決するには、以下の方法を試してください。
ValidateCertChain コマンドライン ユーティリティを使用して、証明書チェーンが受け入れられるかどうかをチェックします。ValidateCertChain の詳細については、「WebLogic Server Java ユーティリティの使い方」の「ValidateCertChain」を参照してください。-Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
次のメッセージは、SSL エラーの原因が証明書チェーンの問題にあることを示します。
CA certificate rejected.The basic constraints for a CA certificate were not marked for being a CA, or were not marked as critical.
一方向 SSL を使用している場合は、クライアント ログでこのエラーを探してください。双方向 SSL を使用している場合は、クライアント ログとサーバ ログでこのエラーを探してください。
-Dweblogic.security.SSL.enforceConstraints コマンドライン引数を使用して制約をより緩やかにするかを決定します。COMMO MBeans の永続性モデルが、WebLogic Server のこのリリースで変更されました。すべてのセキュリティ コンフィグレーション データは、config.xml ファイルに格納されるようになります。既存のセキュリティ コンフィグレーション データは、WebLogic Server 8.1 サーバを最初にブートしたときに config.xml ファイルに書き込まれます。このアップグレードを実行するには、config.xml ファイルを書き込み可能に設定する必要があります。
以前のリリースの WebLogic Server で使用できた Web リソースが、URL リソースにより置換されました。Web リソース (URL リソースではなく) を使用するカスタム認証プロバイダを作成している場合は、[非推奨の Web リソースを使用] 属性を有効にします。この属性によって、サーブレット コンテナの実行時の動作が、認証の実行時に URL リソースではなく Web リソースを使用するように変更されます。
既存の Web リソースを使用するには、次の手順に従います。
WebLogic Server 8.1 では、新しいキーストア実装を使用できます。キーストアは、JDK キーストアから信頼性のある CA、プライベート キー、およびサーバ証明書を取得します。WebLogic Server 8.1 でのキーストア実装では、以下の点が改良されています。
WebLogic Server では、デフォルトで SSL が有効になっており、サーバ ID とその信頼性はデモ用認証、デモ用認証局、および標準 (JDK) 認証局を使用して確立されます。
カスタム キーストア プロバイダは、このリリースの WebLogic Server で使用できなくなりました。プライベート キーと信頼性のある CA は、特定のインスタンスの WebLogic Server に関連付けられたキーストアに格納する必要があります。サーバ用のキーストアのコンフィグレーション方法およびキーストアへのプライベート キーと信頼性のある CA のロード方法の詳細については、Administration Console オンライン ヘルプの「セキュリティ」節の「キーストアおよび SSL のコンフィグレーション」を参照してください。
WebLogic キーストア プロバイダはこのリリースの WebLogic Server で非推奨となりました。プライベート キーと信頼性のある CA のキーストアへの格納に WebLogic キーストア プロバイダを使用している場合は、このリリースの WebLogic Server でサーバを最初に起動したときに、config.xml ファイルの SSL MBean が更新され次の属性が追加されます。
IdentityAndTrustLocations=FilesorKeystoreProviders
この属性によって、新しい SSL ルールではなく、7.x SSL コンフィグレーション ルールの使用が指定されます。このコンフィグレーションの使用は、このリリースの WebLogic Server で使用できるキーストアにアップグレードするまでに限定することをお勧めします。
ID (プライベート キーと証明書) および信頼性 (認証局) のファイルへの格納はサポートされなくなりました。WebLogic Server 8.1 で使用可能なキーストアにアップグレードするには、次の手順に従います。
ImportPrivateKey ユーティリティを使用して実行します。『WebLogic Server コマンド リファレンス』の「ImportPrivateKey」を参照してください。WebLogic Server 7.0 では、Java クライアント (ファット クライアント) は jks キーストアから信頼性のある CA を取得していました。キーストアへのパス名は、次のコマンドライン引数で指定されました。
-Dweblogic.security.SSL.trustCAkeystore
コマンドライン引数が指定されていない場合は、JDK の jre/lib/security/cacerts キーストアにある信頼性のある CA がデフォルトで使用されました。
Java クライアントが信頼性のある CA を取得するこの方法は、次のように改善されました。
WebLogic Server 7.0 で使用した信頼性関連のコマンドライン引数は、このリリースの WebLogic Server でもそのまま使用できます。WebLogic Server 7.0 と同様に、WebLogic Server 8.1 でもデフォルトでは、JDK の jre/lib/security/cacerts キーストアにある信頼性のある CA が使用されます。
このリリースの WebLogic Server での新しい信頼性メカニズムにアップグレードするには、次のいずれかのコマンドライン引数を指定します。
JDK 標準の信頼性のある CA を信頼するには、次のコマンドライン引数を使用します。
-Dweblogic.security.TrustKeystore=JavaStandardTrust
JDK 標準の信頼性のある CA と WebLogic Server によるデモ用の信頼性のある CA を信頼するには、次のコマンドライン引数を使用します。
-Dweblogic.security.TrustKeystore=DemoTrust
カスタム キーストアを使用するには、次のコマンドライン引数を使用します。
-Dweblogic.security.TrustKeystore=CustomTrust
-Dweblogic.security.CustomTrustKeystorePathname=keystorepathname
WebLogic Server の以前のバージョンでは、余分なスペースを含んでいる URI が解決されました。WebLogic Server 8.1 では余分なスペースは解決されなくなり、URI リクエストに余分なスペースが含まれている場合は 404 エラーになります。
たとえば、http://server:port/mywebapp/foo%20%20 は以前は Web アプリケーション「mywebapp」のリソース foo として解決されましたが、8.1 ではこれは行われません。
<check-auth-on-forward> を weblogic.xml ファイルに追加します。application.xml ファイルの context-root 要素を「/」に、スタンドアロンの Web アプリケーションである場合は weblogic.xml ファイルの同要素を「/」に設定します。 weblogic.httpd.servlet.reloadCheckSecs (weblogic.xml servlet-reload-check-secs に置き換えられています)weblogic.httpd.servlet.classpath (代わりにマニフェスト クラスパス、WEB-INF/lib または WEB-INF/classes、または仮想ディレクトリを使用してください)weblogic.httpd.clientCertProxy (weblogic.xml ではまだ置き換えられていません)weblogic.httpd.defaultServlet (代わりに weblogic.xml で pattern=/ を使用して servlet-mapping を定義してください)weblogic.httpd.inputCharset (代わりに weblogic.xml charset-params を使用してください)weblogic.xml ファイルの詳細については、『WebLogic Server Web アプリケーションの開発』の「weblogic.xml デプロイメント記述子の要素」を参照してください。
Web サービスを WebLogic Server 7.0 から WebLogic Server 8.1 にアップグレードするときは、servicegen を再実行して Web サービス デプロイメント ユニットを作成し直す必要があります。
バージョン 7.0 の WebLogic Web サービスから 8.1 へのアップグレードの詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「7.0 WebLogic Web サービスから 8.1 へのアップグレード」を参照してください。
JAX-RPC を使用して WebLogic Web サービスを起動する例については、『WebLogic Web サービス プログラマーズ ガイド』の「クライアント アプリケーションおよび WebLogic Server からの Web サービスの呼び出し」を参照してください。
バージョン 7.0 と 8.1 の Web サービスの違いについては、『WebLogic Web サービス プログラマーズ ガイド』の「WebLogic Web サービスの概要」を参照してください。
すべての仕様変更を確認するには、http://java.sun.com/products/ejb/2.0.html から EJB 2.0 最終仕様を参照またはダウンロードしてください。
WebLogic Server 8.1 で新しい EJB 機能を使用する前に、必ず DDConverter ツールを使用して既存の EJB デプロイメント記述子を 8.1 記述子に変換してください。詳細については、「DDConverter」ツールの説明を参照してください。
WebLogic Server 8.1 では、次の EJB デプロイメント記述子要素でデフォルト値が新しくなりました。
新しいデフォルト値が適用されるのは、WebLogic Server 8.1 で新たに作成したデプロイメント記述子のみです。8.1 よりも前のデプロイメント記述子を使用する既存の Bean は、動作が変更されることなく 8.1 リリースでデプロイできます。
EJB デプロイメント記述子の詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」および「weblogic-cmp-jar.xml デプロイメント記述子のリファレンス」を参照してください。
WebLogic Server 7.0 では、EJB コンテナで一括挿入を実行するには、weblogic-cmp-rdbms-jar.xml の要素 delay-database-insert-until を commit に設定しました。
現在のリリースでは、delay-database-until-insert で commit 値がサポートされなくなりました。一括挿入を実行するには、新しい weblogic-cmp-rdbms-jar.xml の要素 enable-batch-operations を true に設定します。
enable-batch-operations は jar 単位で適用されるため、このタグの設定は jar ごとに 1 回ですみます。delay-database-insert-until では Bean ごとに設定する必要がありました。
エンティティのバッチ処理の詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「処理の順序付けとバッチ処理」を参照してください。
WebLogic Server 8.1 では、7.0 の config.xml ファイルから読み取られたコンフィグレーション情報が、WebLogic Server 8.1 の情報として自動的に取り込まれて更新されます。サーバを複数回、起動する間にもこうした変更を保持するためには、config.xml ファイルを書き込み可能に設定する必要があります。config.xml を読み込み専用にした場合は、書き込みを可能にするため、そのファイル プロパティにアクセスして属性を変更します。たとえば Windows の場合は、Windows エクスプローラでファイルを右クリックして [プロパティ] を選択し、[読み取り専用] 属性のチェックをはずします。
|
|
|