ORACLE JAPAN Server Release 6.1

 
  |  

  WebLogic Server ホーム   |     リリース ノート   |   前へ   |   次へ   |   目次   |   索引   |   PDF 版

WebLogic Server 6.0 アプリケーションの WebLogic Server 6.1 への移行

 

以下の節では、アプリケーションをバージョン 6.0 から 6.1 に移行する手順、および移行の際に注意する事項について説明します。

 

バージョン 6.0 からバージョン 6.1 へのアプリケーションの移行

アプリケーションを WebLogic Server 6.0 から WebLogic Server 6.1 に移行するには、次の手順に従います。

  1. WebLogic Server 6.1 をインストールします。

    注意: 古いバージョンの上に直接、新しいバージョンをインストールすることは、インストーラによって明示的に禁止されています。

  2. WebLogic Server 6.1 に移行するコンフィグレーション ドメインごとに、ドメイン ディレクトリを WL_HOME\config ディレクトリにコピーします。このディレクトリは、WebLogic Server 6.1 のすべてのコンフィグレーション ドメインの格納に使用されます。バージョン 6.0 の config ディレクトリが WebLogic Server 6.0 配布キット内にない場合は、WebLogic Server 6.1 で WebLogic 6.0 コンフィグレーションを再利用してもかまいません。

    1. config.xml で参照されるすべての外部ファイルを確認します。WebLogic Server のコンフィグレーションは、ファイル システムに格納されるファイルに基づきます。通常、これらのファイルは、永続性リポジトリ（ログ ファイル、ファイルベースのリポジトリなど）またはユーティリティ（Java コンパイラ）であり、絶対パスまたは相対パスを使用してコンフィグレーションされます。

      すべての外部ファイルが相対パスで定義され、ドメイン ディレクトリ内またはその下位にある場合は、手順 3.b に進んでください。

      外部ファイルがドメイン ディレクトリの外部を示す相対パスで定義されている場合は、新しい config ディレクトリを基準にしたディレクトリ構造を再作成し、関連付けられるファイルを新しいディレクトリにコピーします。外部ファイルが絶対パスで定義されている場合は、これらのファイルが WebLogic Server 6.1 デプロイメントで適切に再利用できるかどうかを確認します。

      たとえば、ログ ファイルおよび永続性ストレージは再利用できますが、Java コンパイラなどのユーティリティは最新バージョンを使用するためには更新が必要になる場合もあります。更新が必要なファイルについては、新しいファイルまたはユーティリティを使用するよう、WebLogic Server 6.0 Administration Console を使用して適切な属性を再コンフィグレーションしてから、次の手順に進みます。

      デプロイメント記述子（web.xml および weblogic.xml）についても検討する必要があります。Java コンパイラなどの項目へのファイル パスが含まれている場合があるからです。

    2. 適切なドメイン ディレクトリおよび console.war 以外のすべてのサブコンポーネント（ディレクトリとファイル）を、手順 2 で作成した config ディレクトリにコピーします。

      すべてのトランザクション ログ（*.tlog）と数多くのメッセージ キューも必ず、ドメインと共に移動させてください。

  3. WebLogic Server 6.1 ライブラリを使用するように、新しいドメインのサーバ起動スクリプトを編集します。

    CLASSPATH -

    WebLogic Server 6.1 配布キットの weblogic.jar を含める必要があります。

    java.security.policy property -

    WebLogic Server 6.1 配布キットの weblogic.policy ファイルを指す必要があります。

    bea.home property -

    WebLogic Server 6.1 の license.bea ファイルを含む BEA ホーム ディレクトリを指す必要があります。

 

JMS

WebLogic 6.0 から WebLogic Server 6.1 に移行する際には、以下の事項を考慮してください。

WebLogic JMS アプリケーションの旧バージョンを移行する方法の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移行」を参照してください。

 

EJB 2.0

Sun Microsystem の EJB 2.0 仕様は、WebLogic Server のバージョン 6.0 と 6.1 の間で変更されています。そのため、デプロイメント記述子ディレクティブの中にはサポートされなくなったものがあります。これは、WebLogic Server 6.0 のアプリケーションは変更しなくても WebLogic Server 6.1 のサーバで機能するという、WebLogic Server 6.0 から 6.1 の移行ルールの例外になっています。WebLogic Server 6.0 で機能した EJB 1.1 Bean は、変更しなくても WebLogic Server 6.1 で機能します。

Weblogic 6.1 では、新しいインタフェース EJBComponentMBean によって ComponentMBean と EJBContainerMBean の両方が拡張されます。EJBComponentMBean を実装するすべてのカスタム Mbean（getVerboseEJBDeploymentEnabled など）は、WebLogic Server 6.0 から 6.1 に移行する際にこのインタフェースをサポートするように修正する必要があります。EJBContainerMBean が拡張されると、EJBComponentMBean はその EJBComponentMBean が EJB コンテナでなくても EJBContainerMBean と同じメソッドを提供します。

EJB 2.0 セッション Bean と BMP エンティティ Bean のアップグレード

EJB 2.0 セッション Bean または BMP エンティティ Bean モデルに大きな変更はありません。WebLogic Server 6.1 で WebLogic EJB コンパイラ（ejbc）を再実行すると、ejb-jar.xml ファイルが確実に最新の EJB 2.0 DTD に準拠します。

EJB 2.0 メッセージ駆動型 Bean（MDB）のアップグレード

ejb-jar.xml ファイルで、メッセージ駆動型 Bean の EJB 2.0 デプロイメント記述子要素が変更されています。<jms-acknowledge-mode> は <acknowledge-mode> に変更する必要があり、<jms-destination-type> は <destination-type> になりました。

WebLogic Server 6.0 のメッセージ駆動型 Bean ユーザは、デプロイメント記述子に <run-as-specified-identity> というタグがある場合があります。このタグは WebLogic Server 6.0 でサポートされていず、その名前は最新の EJB 2.0 の変更で <run as> に変更されています。WebLogic Server 6.0 ではこの機能がサポートされていなかったので、ほとんどの 6.0 メッセージ駆動型 Bean ユーザは run-as デプロイメントを必要とせず、この要素を ejb-jar.xml ファイルから削除できます。run-as ID が必要な場合は、ejb-jar.xml ファイルでその要素を <run-as> に変更する必要があります。

EJB 2.0 CMP エンティティ Bean のアップグレード

EJB 2.0 仕様では、CMP 2.0 モデルが多くの点で変更されています。

最初のステップは、ejb-jar.xml ファイルを確実に最新の EJB 2.0 DTD に準拠させることです。要素の名前がいくつか変更されています。<role-source> タグは、<relationship-role-source> という名前になりました。<run-as-specified-identity> タグは、<run-as> になっています。

最新の EJB 2.0 仕様では、ローカル インタフェースという概念が導入されています。EJB の関係は、ローカル インタフェースに基づくようになりました。関係に関与するすべての EJB では、ローカル インタフェースが必要です。

リモートの関係は、EJB 2.0 仕様から削除されました。WebLogic Server での関係は現在は EJB 2.0 CMP エンティティ Bean 間だけであり、関係する Bean は同じ EJB JAR ファイルにデプロイする必要があります。

 

JMX

WebLogic Server 6.0 のすべてのパブリックな MBean および属性は、WebLogic Server 6.1 でサポートされています。ただし、内部 MBean または属性を使用している場合には、移行の問題に直面するかもしれません。

 

Apache XML パーサ

XML WebLogic Server 6.0 -> 6.1 パーサが更新されており、現在は Apache Xerces 1.3.1 パーサに基づいています。このパーサでは、SAX インタフェースおよび DOM インタフェースのバージョン 2 が実装されています。以前のバージョンで提供されていた古いパーサを使用すると、旧式であることを示すメッセージが表示される場合があります。

xmlx.jar ファイルで提供されるパーサは非推奨になっていますが、下位互換性を目的として提供されます。外部パーサを使用する場合は、JAXP を通じて使用する必要があります。非 JAXP コードから JAXP コードへの移行では、コードの調整が必要になる場合があります。

 

Xalan XML パーサ

Xalan API は非推奨になりました。それらの API を依然として使用して問題が発生する場合は、JAXP API を使用して XSLT を使用することをお勧めします。

Apache の Xalan コードは、Xerces と Xalan を一緒に使用できるように変更が行われました。それらの変更が含まれないので、Apache から Xalan を使用すると問題が発生する場合があります。

通常は、JAXP を使用し、ベンダ固有のコードを SAX、DOM、および XSL 処理用に JAXP などのニュートラルな API に移行するのが最適です。

 

Web アプリケーション

weblogic.management.descriptors.webapp.ServletMBean.getName() API（WebLogic Server 6.0）は、WebLogic Server 6.1 で weblogic.management.descriptors.webapp.ServletMBean.getServletName() に変更されています。このインタフェースを使用する場合は、ソース コードをアップデートして再コンパイルする必要があります。

Java サーブレット仕様 2.3 では、転送時の認可がデフォルトでは行われなくなりました。セキュアなリソースへの転送時に認可を得るには、<check-auth-on-forward> を weblogic.xml に追加します。

サーブレットのリクエスト オブジェクトと応答オブジェクトには新しい API があります。それらのオブジェクトのシリアライズ可能で軽量な一部の実装は、新しい API を実装しないとコンパイルされない可能性があります。新しいサーブレット 2.3 モデルを使用し、サーブレットのリクエスト オブジェクトと応答オブジェクトの実装を置換することをお勧めします。WebLogic Server 6.0 でこれを行った場合は、それらのオブジェクトの文書化されていない内部実装に基づいているものと思われます。WebLogic Server 6.1 ではサーブレット 2.3 がサポートされているので、新しい ServletRequest/ResponseWrapper オブジェクトを利用できます。

 

セキュリティ

サーバのデフォルトの状態では、すべての MBean に対して最も厳しいアクセス制御リスト（ACL）が課されます。したがって、非システム ユーザとして MBean をプログラム的に変更すると、制限を緩めない限りアクセスが拒否されます。

 

config\applications ディレクトリ

WebLogic Server 6.1 では、実行時モードによって「開発」モードと「プロダクション」モードの 2 つのモードに区別されます。実行時モードは、Weblogic 管理サーバの起動時にコマンドライン パラメータを使用して選択します（-Dweblogic.ProductionModeEnabled=true | false）。このパラメータを設定しないと、サーバは開発モードで動作します。開発モードでは、サーバの動作は WebLogic Server 6.0 の場合と同じです。ただし、プロダクション モードの場合には自動デプロイメント機能が無効になります。コンフィグレーション リポジトリ（config.xml）で明示的にデプロイされない applications ディレクトリのデプロイメント ユニットは、自動的にはデプロイされません。WebLogic Server 6.1 では、デフォルト（mydomain）コンフィグレーションと Pet Store コンフィグレーションは開発モードで提供されます。サンプル コンフィグレーションは、開発モードで提供されます。applications ディレクトリで変更を調査する AppManager スレッドが管理サーバだけで作成されるので、この機能は管理サーバでのみ機能します。

 

Solaris での WebLogic Server クラスタ

Solaris 上の WebLogic Server クラスタにデプロイされた特定のアプリケーション（重い EJB アプリケーション）は、サーバ JVM ではなくクライアント JVM を使用することでパフォーマンスが向上します。このことは、負荷の大きな状況で特に顕著になります。

 

スレッド プールのサイズ

WebLogic Server 6.0 では、ワーカ スレッドの数はサーバ MBean の ThreadPoolSize パラメータで指定しました。WebLogic Server 6.1 からは、ワーカ スレッドの数はサーバ MBean の ExecuteQueue で定義します。

WebLogic Server 6.1 ではこのパラメータの移行パスが提供されるので、それが config.xml で指定される場合、またはコマンドラインでクライアントかサーバに渡される場合（-Dweblogic.ThreadPoolSize=<xx>）、ThreadPoolSize が自動的に ThreadCount 設定に移行されます。

WebLogic Server 6.1 サービス パック 1 では、コンソールのバグによって、ThreadCount に不正確な値（デフォルト値）が表示されていました。ただし、これはコンソールの中だけでのバグであり、クライアントおよびサーバでは正確な数のスレッドが使用されていました。

ワーカ スレッド数は次のように設定します。

WebLogic Server 6.0 の場合
<Server
Name="myserver"
ThreadPoolSize="23"
...
/Server>

WebLogic Server 6.1 以降

<Server
Name="myserver"
... >
<ExecuteQueue
Name="default"
ThreadCount="23" />
/Server>

コンソールでスレッド数の値を変更するには、次の手順を行います。

  1. コンソールで、[サーバ｜myServer｜モニタ] を選択します。

  2. [すべてのアクティブなキューのモニタ] をクリックします。

  3. 「default」キューをクリックします（スレッドとそれらのスレッドの処理内容のリストが表示される）。

  4. [Execute Queues のコンフィグレーション]（ページの最上部）をクリックします。

  5. 「default」キューをクリックします。

  6. このサーバと関連付けられているスレッド数を入力します。

  7. サーバを再起動して変更を有効にします。

 

back to top previous page next page