BEA ホーム | 製品 | dev2dev | support | askBEA
 ドキュメントのダウンロード   サイト マップ   Glossary 
検索

WebLogic Server 7.0 へのアップグレード

 Previous Next Contents PDF で侮ヲ  

WebLogic Server 4.5 および 5.1 からバージョン 7.0 へのアップグレード

WebLogic Server 4.5 および 5.1 からバージョン 7.0 へのアップグレードは、Web アプリケーションを定義し、weblogic.properties ファイルを新しい XML ファイル形式に変換する複数の手順からなるプロセスです。また、アップグレード プロセスに影響するいくつかの仕様上の変更も行われています。この章ではアップグレードに関連する問題の大半を扱っていますが、特定の環境に固有の問題については説明を省略している場合があります。

以下の節では、システムを WebLogic Server 4.5 または 5.1 から WebLogic Server 7.0 にアップグレードする場合、またアプリケーションを WebLogic Server 4.5 または 5.1 から WebLogic Server 7.0 に移植してデプロイする場合に必要な手順およびその他の情報を示します。説明する内容は、WebLogic Server 4.5 と 5.1 の両方から WebLogic Server 7.0 へのアップグレードを対象としています。

注意: このマニュアル全体を通して、「アップグレード」という用語は、WebLogic Server のより新しいバージョンへのアップグレードを指します。 また「移植」という用語は、アプリケーションを WebLogic Server の古いバージョンからより新しいバージョンに移動することを指します。

 


WebLogic Server コンフィグレーションのアップグレード : 主な手順

WebLogic Server 4.5 または 5.1 から WebLogic Server 7.0 にアップグレードするには、次の手順に従います。

  1. アップグレードの手順を開始する前に、バージョン 4.5 または 5.1 のドメインのバックアップ コピーを作成します。WebLogic Server 7.0 クラスを使用してサーバを起動した後で、前のバージョンにダウングレードすることはできません。

  2. WebLogic Server 7.0 をインストールします。『インストール ガイド』を参照してください。

    WebLogic Server 6.0 よりも前のバージョンでは、56 ビット暗号ではなく 128 ビット暗号を使用する場合に別途のダウンロードが必要でした。WebLogic Server 7.0 では、56 ビット暗号と 128 ビット暗号の両方に対応した単一のダウンロードが用意されています。128 ビット暗号を有効にする方法については、『インストール ガイド』の「128 ビット暗号の有効化」を参照してください。

    注意: 古いバージョンと同じ場所に新しいバージョンをインストールしようとすると、インストーラにより警告が出されます。

  3. サーバのライセンス ファイルをアップグレードします。ライセンスを新しい形式に変換する方法については、WebLogic Server ライセンス ファイルのアップグレードを参照してください。

  4. weblogic.properties ファイルを変換します。weblogic.properties ファイルを変換する方法については、weblogic.properties ファイルから XML ファイルへの変換および Administration Console オンライン ヘルプを参照してください。

  5. コンソールに表示されたウィンドウで、新しい管理サーバの名前を入力します。この名前は、管理サーバのサーバ名として使われます。指定しない場合、名前はデフォルトの myserver になります。

  6. 変換結果の出力が生成されるディレクトリを入力します。元のドメインを変換した結果として作成されるすべてのファイルおよびサブディレクトリは、ここで指定するディレクトリ内に配置されます。

  7. Java システム CLASSPATH にクラスを追加します。詳細については、WebLogic Server 7.0 でのクラスのロードを参照してください。

  8. WebLogic Server 7.0 で動作するように既存の起動スクリプトを修正します。起動スクリプトの修正を参照してください。

  9. WebLogic サーバサイド ビジネス オブジェクト実装 (WebLogic Server 6.0 以降 Web アプリケーションと呼ばれる) を、WebLogic 7.0 上で実行するためにパッケージ化し、移植します。既存のアプリケーションの Web アプリケーションへの変換と移植を参照してください。

  10. EJB の移植が必要な場合は、エンタープライズ JavaBean アプリケーションの移植と変換を参照してください。

  11. JMS をアップグレードします。WebLogic Server 4.5 以降、多くの新しいコンフィグレーション属性が JMS に追加されています。詳細については、JMS のアップグレードを参照してください。

サーバのクラスタをアップグレードするには、それぞれのサーバについて上記の手順に従い、その後、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic クラスタのセットアップ」で説明されている手順に従います。バージョン 4.5 と 7.0、または 5.1 と 7.0 の間では相互運用性がないため、クラスタを構成するすべてのサーバでバージョン 7.0 を実行していることが推奨されます。

WebLogic Server 7.0 から WebLogic Server 7.0.0.1 にアップグレードするには、『インストール ガイド』の「ebLogic Server 7.0 GA (7.0.0.0) から 7.0.0.1 へのアップデート」を参照してください。

注意: WebLogic Server 7.0 のディレクトリ構造は、4.5 および 5.1 のものと異なります。新しくなったディレクトリ構造の詳細については、『インストール ガイド』の「WebLogic Server のディレクトリ構造について」を参照してください。

 


WebLogic Server ライセンス ファイルのアップグレード

Java 形式のライセンス ファイル (WebLogicLicense.class) および XML 形式のライセンス ファイル (WebLogicLicense.XML) は、現在はサポートされていません。これらのファイルは以前のバージョンの WebLogic Server で使われていたもので、新しい形式に変換する必要があります。新しいライセンス ファイルは license.bea です。

ライセンス・アップグレードに際してのご注意

ライセンス・アップグレードは、お客様が製品を購入された販売元にご依頼ください。

お客様が「日本 BEA システムズ販売パートナ」から WebLogic Server をご購入された場合は、販売パートナへお問い合わせ、ご依頼ください。弊社販売パートナがライセンスのアップグレードを行い、新しいライセンスファイルをお届けいたします。

お客様が日本 BEA システムズ (株) から直接 WebLogic Server をご購入された場合は、日本 BEA システムズの営業担当者へご依頼ください。日本 BEA システムズよりアップグレードされたライセンスファイルをお届けいたします。

WebLogicLicense.class ライセンスの変換

既存の WebLogic Server インストールで WebLogicLicense.class ファイルを使用していた場合は、WebLogic Server 7.x をインストールする前に以下のタスクを実行します。

  1. licenseConverter ユーティリティを使用して、WebLogicLicense.class ライセンス ファイルを WebLogicLicense.XML ファイルに変換します。

  2. WebLogicLicense.XML ライセンスの変換で説明するように、WebLogicLicense.XML ファイルを変換します。

WebLogicLicense.XML ライセンスの変換

WebLogicLicense.XML ファイルを、WebLogic Server 6.x および 7.x と互換性のある license.bea ファイルに変換するには、以下の手順を実行します。この手順を実行するマシンで、WebLogicLicense.XML ライセンス ファイルが使用できることを確認してください。

  1. BEA カスタマ サポートの Web サイト (http://websupport.beasys.com/custsupp) にログインします。

  2. WebLogic Server ライセンスを更新するためのリンクをクリックします。リンクを表示するために下の方にスクロールした方がよいこともあります。

  3. 変換するライセンス ファイルの入ったディレクトリのパス名を参照して選択するか、表示されるボックスにパス名を入力します。[Submit License] をクリックします。

  4. 変換済みの license_wlsxx.bea ファイルが電子メールで返送されます。システムにある license.bea ファイルを更新するには、『インストール ガイド』の「license.bea ファイルの更新」を参照してください。

 


weblogic.properties ファイルから XML ファイルへの変換

注意: このマニュアル全体を通して、ユーザが作成する WebLogic Server 7.0 のディレクトリ ドメインを domain と表記します。

WebLogic Server 6.0 以前のリリースでは、アプリケーションのコンフィグレーションに weblogic.properties ファイルを使用していました。WebLogic Server 7.0 では、アプリケーションのコンフィグレーションは XML 記述子ファイルと Administration Console を使用して処理します。weblogic.properties ファイルを config.xml ファイルに変換すると、アプリケーションの新しいドメインが作成され、アプリケーションのセットアップ内容を定義する XML ファイルが追加されます。変換の間に作成されるデフォルトのドメイン名は、アプリケーションの内容に関連性のある名前に変更することをお勧めします。

config.xml ファイルは、WebLogic Server ドメイン全体のコンフィグレーションを記述した XML ドキュメントです。config.xml ファイルは XML 要素群で構成されています。domain 要素はトップレベルの要素であり、domain 内のすべての要素は domain 要素の子です。domain 要素には serverclusterapplication などの子要素が含まれます。これらの子要素の中にさらに子要素がある場合もあります。各要素には、コンフィグレーション可能な 1 つ以上の属性があります。

weblogic.xml ファイルには、Web アプリケーションで使われる WebLogic 固有の属性が格納されます。このファイルでは HTTP セッション パラメータ、HTTP クッキー パラメータ、JSP パラメータ、リソース参照、セキュリティ ロールの割り当て、文字セット マッピング、およびコンテナ属性の各属性を定義します。

デプロイメント記述子の web.xml ファイルは、Sun Microsystems のサーブレット 2.3 仕様で定義されています。web.xml ファイルは個々のサーブレットおよび JSP ページを定義し、Web アプリケーションで参照されるエンタープライズ Bean を列挙します。このデプロイメント記述子を使用して、J2EE 準拠のアプリケーション サーバに Web アプリケーションをデプロイできます。

既存の weblogic.properties ファイルを適切な XML ファイルに変換するには、次の手順に従います。

  1. WebLogic Server 7.0 のサンプル サーバを起動します。WebLogic Server 7.0 のサンプル サーバを起動する方法については、「インストール後の作業の実行」の「サンプル サーバ、Pet Store サーバ、および Workshop サンプル サーバの起動」を参照してください。

    ユーザ名とパスワードの入力を求められます。

  2. WebLogic Administration Console のホーム ページ (http://localhost:7001/console/index.jsp など) で、[ツール] の見出しの下にある [weblogic.properties をコンバート] リンクをクリックします。

  3. コンソールのリンクを使用して、サーバのファイル システム内を移動し、以前のバージョンの WebLogic Server のルート ディレクトリ (C:¥weblogic など) を見つけます。ルート ディレクトリが見つかったら、その隣にあるアイコンをクリックして選択します。

  4. それ以外に、サーバ別の weblogic.properties ファイルやクラスタ化 weblogic.properties ファイルがほかのディレクトリにある場合は、表示されているウィンドウを使用してそれらのファイルを選択します。以前のバージョンの WebLogic Server のルート ディレクトリが正しく選択されていれば、選択した追加の properties ファイルに関係なく、グローバルの weblogic.properties ファイルが変換されます。

  5. コンソールに表示されたウィンドウで、新しいドメインの名前を入力します。[コンバート] をクリックします。

properties ファイルを変換するとき、デフォルト Web アプリケーション用の web.xml および weblogic.xml ファイルが自動的に作成され、domain¥applications¥DefaultWebApp_myserver¥WEB-INF ディレクトリの内部に配置されます。weblogic.properties ファイルを変換する過程では、domain ディレクトリに配置される config.xml ファイルも作成されます。このファイルには、ドメインに固有のコンフィグレーション情報が格納されます。

注意: ここまでに説明した変換ユーティリティでは、weblogic.xml ファイルで Java ホームの場所を指定します。変換ユーティリティは System.getProperty(java.home) を使用してこの場所を読み取ります。 つまり、変換のために WebLogic Server が起動された Java ホームの場所が指定されます。

weblogic.properties ファイルを変換する手順については、Administration Console オンライン ヘルプを参照してください。

以前に weblogic.properties のプロパティによって実行されていた機能を、config.xml、web.xml、または weblogic.xml のどの属性で処理するのかのリストについては、weblogic.properties のマッピング表を参照してください。

weblogic.properties ファイルの変換時に生成される起動スクリプトの名前は次のとおりです。

domainNamedomain ディレクトリの名前です。

これらのスクリプトは、WebLogic Server 7.0 配布キットの domain ディレクトリに収められており、新しいドメインで管理サーバを起動します。

スクリプトとサーバの起動の詳細については、『管理者ガイド』の「WebLogic Servers の起動と停止」を参照してください。

 


WebLogic Server 7.0 でのクラスのロード

WebLogic Server の以前のバージョンでは、クラスの動的なロードを容易にするために WebLogic クラスパス プロパティ (weblogic.class.path) が使用されていました。WebLogic 6.0 以降のバージョンでは、weblogic.class.path は必要ありません。現在は、Java システム クラスパスからクラスをロードできます。

以前に weblogic.class.path で指定していたクラスを標準の Java システム クラスパスに含めるには、CLASSPATH 環境変数を設定するか、または次の例のようにコマンドライン上で -classpath オプションを使用します。

java -classpath %CLASSPATH%;%MyOldClassspath% weblogic.Server

%MyOldClasspath% には、古いアプリケーションを指し示すディレクトリだけを指定します。

 


起動スクリプトの修正

以前のバージョンで WebLogic Server 起動スクリプトを使用していた場合は、バージョン 7.0 で利用できるようにスクリプトを変更する必要があります。

 


WebLogic Server 7.0 の J2EE アプリケーション タイプ

WebLogic Server 7.0 などの J2EE 準拠のサーバ上で動作するアプリケーションは、 Web アプリケーション、エンタープライズ JavaBean、エンタープライズ アーカイブ、およびクライアント アプリケーションの 4 つのタイプのいずれかとして作成およびデプロイされます。既存のコンポーネントを WebLogic Server 7.0 に移植するには、適切な J2EE デプロイメント ユニットを作成します。J2EE デプロイメント ユニットの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「エンタープライズ アプリケーションの一部としての Web アプリケーションのデプロイ」を参照してください。Web アプリケーションは通常はサーブレット、JSP、および HTML ファイルの集合であり、WAR ファイルとしてパッケージ化されます。(JAR ファイルとしてパッケージ化される) エンタープライズ JavaBean は、EJB 仕様に従って記述されるサーバサイド Java コンポーネントです。エンタープライズ アーカイブ (EAR ファイル) には、アプリケーションのすべての JAR および WAR コンポーネント アーカイブ ファイルと、ひとまとめにされるコンポーネント群を記述する XML 記述子が格納されます。クライアント アプリケーションは、Remote Method Invocation (RMI) を使用して WebLogic Server に接続する Java クラスです。前述の J2EE デプロイメント ユニットについては、後の節で詳しく説明します。

 


既存のアプリケーションの Web アプリケーションへの変換と移植

アプリケーションを Web アプリケーションに変換し、WebLogic Server 7.0 上にデプロイされる Web アプリケーションに移植するためには、特定のパターンに従うディレクトリ構造の内部にアプリケーションの構成ファイル群を配置する必要があります。開発段階では、これらのファイルはどのようなディレクトリ形式で配置しておいてもかまいません。ただし、プロダクション段階では、アプリケーションを WAR ファイルに 1 つの Web アプリケーションとしてまとめることを強くお勧めします。Web アプリケーションの詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server J2EE アプリケーションについて」および『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。

以下の節では、WebLogic Server 5.1 から WebLogic Server 7.0 に単純なサーブレットを移植する手順など、Web アプリケーションの移植およびデプロイメントについて知っておく必要がある情報を示します。

Web アプリケーションのディレクトリ構造

Web アプリケーションは、アーカイブ化して WebLogic Server 上にデプロイできるように、あらかじめ定められたディレクトリ構造に整理されます。Web アプリケーションに属するすべてのサーブレット、クラス、静的ファイル、およびその他のリソースはディレクトリ階層の下に整理されます。この階層構造のルートは、Web アプリケーションのドキュメント ルートを定義します。このルート ディレクトリの下に置かれたファイルは、ルート ディレクトリ内の WEB-INF および META-INF という特別なディレクトリの下にあるファイルを除いて、すべてクライアントに対して何らかの働きをします。ルート ディレクトリの名前は Web アプリケーションと同じにすることが推奨されます。

次の図は、Web アプリケーションのディレクトリ構造を示したものです。

WebApplicationRoot¥(.jsp、.html、.jpg、.gif などの
| 公開されるファイル)
|
+WEB-INF¥-+
|
+ classes¥(Web アプリケーションによって
| 使われるサーブレットなどの
| Java クラスを格納する
| 格納するディレクトリ)
|
+ lib¥(Web アプリケーションによって
| 使われる JAR ファイルを
| 格納するディレクトリ)
|
+ web.xml
|
+ weblogic.xml

weblogic.properties ファイルを変換すると、domain¥applications¥DefaultWebApp_myserver¥WEB-INF ディレクトリの下に、適切な weblogic.xml ファイルと weblogic.xml ファイルが自動的に作成されます。上記のディレクトリ構造に従って、ユーザが作成する domain¥applications¥webAppName¥WEB-INF ディレクトリに XML ファイルを配置します。Web アプリケーションのデプロイメントの詳細については、『WebLogic Server アプリケーションの開発』を参照してください。

XML デプロイメント記述子

Web アプリケーションのデプロイメント記述子 (web.xml) ファイルは標準の J2EE 記述子であり、サーブレットの登録、サーブレット初期化パラメータの定義、JSP タグ ライブラリの登録、セキュリティ制約の定義、およびその他の Web アプリケーション パラメータの定義に使用されます。デプロイメント記述子を作成する手順については、『Web アプリケーションのアセンブルとコンフィグレーション』の「web.xml デプロイメント記述子の記述」を参照してください。

WebLogic 固有のデプロイメント記述子 (weblogic.xml) もあります。このファイルでは、JSP プロパティ、JNDI のマッピング、セキュリティ ロールのマッピング、および HTTP セッション パラメータを定義します。WebLogic 固有のデプロイメント記述子では、web.xml ファイルで指定されたリソースが WebLogic Server のどのリソースにどのようにマップされるのかも定義します。WebLogic 固有のデプロイメント記述子を作成する手順については、「WebLogic 固有のデプロイメント記述子の記述」を参照してください。前述のプロパティ、マッピング、またはパラメータが不要な場合には、このファイルが必要でない場合があります。

web.xml ファイルと weblogic.xml ファイルは、アプリケーションをコンフィグレーションするために Administration Console と組み合わせて使用します。XML ファイルの内容は任意のテキスト エディタで表示できます。ファイルの内容を編集するには、必要な変更を行ってから、Web アプリケーションのディレクトリ構造に示したディレクトリ構造によって規定される適切なパスに web.xml または weblogic.xml の名前でファイルを保存します。詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。アプリケーション群を 1 つの Web アプリケーションとしてまとめてデプロイしない場合は、自動的に作成された XML ファイルを分割し、各 Web アプリケーションに固有の適切な XML ファイルを作成する必要があります。各 Web アプリケーションには、アプリケーションで使用するように選択したファイルに加えて、weblogic.xml ファイルと web.xml ファイルが必要です。

WAR ファイル

WAR ファイルは Web アプリケーションのアーカイブです。前に説明した Web アプリケーションのディレクトリ構造に正しく従っており、適切な web.xml ファイルと weblogic.xml ファイルが作成済みである場合、プロダクション環境ではできる限り、アプリケーション群を WAR ファイルとしてデプロイされる 1 つのアプリケーションにまとめるようにしてください。アプリケーションを WAR ファイルにまとめた後は、WebLogic Server 上の各アプリケーションのインスタンスが 1 つだけになるように、以前のディレクトリ構造を削除することが重要です。

WAR ファイルを作成するには、Web アプリケーションのあるルート ディレクトリで次のコマンドラインを使用します。「webAppName」の部分は、Web アプリケーションに対して設定した独自の名前に置き換えてください。

jar cvf webAppName.war *

これにより、Web アプリケーションのすべてのファイルおよびコンフィグレーション情報を格納した WAR ファイルが作成されます。

Web アプリケーションのデプロイメント

WebLogic Server Administration Console を使用して Web アプリケーションをコンフィグレーションおよびデプロイするには、次の操作を行います。

  1. WebLogic Server Administration Console を起動します。

  2. 作業を行うドメインを選択します。

  3. Administration Console の左ペインで、[デプロイメント] をクリックします。

  4. Administration Consoleの左ペインで [アプリケーション] をクリックします。Administration Consoleの右ペインに、すべてのデプロイメント済みアプリケーションを示すテーブルが表示されます。

  5. [新しい Application のコンフィグレーション] オプションを選択します。

  6. アプリケーション アーカイブ、または展開されたアプリケーションが格納されたディレクトリの場所を確認します。WebLogic Sever は、指定したディレクトリおよびその下位ディレクトリで見つかった全コンポーネントをデプロイします。

  7. ディレクトリまたはファイルの左のアイコンをクリックして選択し、次の操作に進みます。

  8. 表示されたフィールドにアプリケーションまたはコンポーネントの名前を入力して、[作成] をクリックします。

  9. 以下の情報を入力します。

    [ステージング モード] - ステージング モードを指定します。

    [デプロイ] - 表示されているチェックボックスを使用して、作成時に .ear、.war、.jar、または .rar ファイルをデプロイするかどうかを示します。

  10. アプリケーションのコンポーネントをコンフィグレーションするために、[このアプリケーションのコンポーネントをコンフィグレーション] をクリックします。

  11. [コンポーネント] テーブルが表示されます。コンフィグレーションするコンポーネントをクリックします。

  12. 使用できるタブで、以下の情報を入力します。

    [コンフィグレーション] - ステージング モードを編集し、デプロイメント順を入力します。

    [対象] - アプリケーションを [選択可] リストから [選択済み] リストに移動することによって、このコンフィグレーション対象のアプリケーションの対象サーバを指定します。

    [デプロイ] - 選択したすべての対象にアプリケーションをデプロイするか、またはすべての対象からアプリケーションをアンデプロイします。

    [モニタ] - アプリケーションに関連するモニタ情報を表示します。

    [メモ] - アプリケーションについての注記事項を入力します。

  13. [適用] をクリックします。

コンソールでの属性の設定については、Administration Console オンライン ヘルプの「Web アプリケーション」の節を参照してください。

セッションの移植

WebLogic Server 6.0 でクッキーの形式が変更されたため、WebLogic Server 7.0 では、バージョン 6.0 以前のクッキーが認識されません。古い形式のクッキーは無視され、新しいセッションが作成されます。新しいセッションは自動的に作成される点に注意してください。

クッキーのデフォルト名はバージョン 5.1 から変更されています (以前の名前は WebLogicSession)。WebLogic Server 7.0 では、クッキーのデフォルト名は JSESSIONID です。

詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「weblogic.xml デプロイメント記述子の要素」を参照してください。

JavaServer Pages (JSP) とサーブレット

この節では、アプリケーションで使用できる JSP およびサーブレットに固有の情報を示します。

WebLogic Server 5.1 から WebLogic Server 7.0 への単純なサーブレットの移植

次の手順では、WebLogic Server 5.1 で提供されていた単純な Hello World サーブレットを WebLogic Server 7.0 に移植します。

  1. WebLogic Server 7.0 で、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「管理とコンフィグレーション」での説明に従って正しいディレクトリ構造を作成します。この作業ではルート アプリケーション ディレクトリ (C:¥hello など) を作成し、その下に C:¥hello¥WEB-INF ディレクトリと C:¥hello¥WEB-INF¥classes ディレクトリを作成します。HelloWorld.Servlet.java ファイルを C:¥hello¥WEB-INF¥classes ディレクトリに配置します。

  2. このサーブレットの web.xml ファイルを作成します。weblogic.properties ファイルを変換した場合、web.xml ファイルは既に自動的に作成されています。weblogic.properties ファイルを変換する前にこのファイルに HelloWorldServlet を登録した場合、サーブレットは新しい web.xml ファイル内で適切にコンフィグレーションされます。XML ファイルは任意のテキスト エディタを使って作成できます。HelloWorldServlet で使用できる基本的な web.xml ファイルの例を次に示します。
    <!DOCTYPE web-app (完全な DOCTYPE 宣言についてはソースを参照...)> 
    - <web-app>
    - <servlet>
    <servlet-name>HelloWorldServlet</servlet-name>
    <servlet-class>examples.servlets.HelloWorldServlet</servlet-class>
    </servlet>
    - <servlet-mapping>
    <servlet-name>HelloWorldServlet</servlet-name>
    <url-pattern>/hello/*</url-pattern>
    </servlet-mapping>
    </web-app>

    web.xml ファイルの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「Web アプリケーションのデプロイメント記述子の記述」を参照してください。weblogic.xml ファイルは、HelloWorld のようなスタンドアロンの単純なサーブレットでは必要ありません。

    weblogic.xml ファイルの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「WebLogic 固有のデプロイメント記述子の記述」を参照してください。

  3. web.xml ファイルを、domain¥applications¥DefaultWebApp_myserver¥WEB-INF ディレクトリから C:¥hello¥WEB-INF¥ ディレクトリに移動します。

  4. 開発環境をセットアップし (『WebLogic Server アプリケーションの開発』の「開発環境の構築」を参照)、次のようなコマンドを使用して HelloWorldServlet をコンパイルします。
    C:¥hello¥WEB-INF¥classes>javac -d  . HelloWorldServlet.java

    これにより、ファイルがコンパイルされ、正しいパッケージ構造が作成されます。

  5. この時点で、次のコマンドを使用してサーブレットをアーカイブの WAR ファイルにまとめることができます。
    jar cvf hello.war *

    これにより、hello.war ファイルが作成されて C:¥hello ディレクトリ内に配置されます。

  6. この Web アプリケーションをインストールするには、サーバを起動して Administration Console を開きます。[はじめに] メニューの下にある [アプリケーションのインストール] を選択します。新しく作成した WAR ファイルを選択して [Upload] をクリックします。

    サーブレットがデプロイされ、コンソールの左ペインにある [デプロイメント] の下の [Web アプリケーション] ノードの下に表示されます。

  7. サーブレットを呼び出すには、Web ブラウザのアドレス欄に http://localhost:7001/hello/hello と入力します。

この場合、/hello/ はサーブレットのコンテキスト パスです。このパスは WAR ファイルの名前に基づいて決定され、この場合は hello.war です。2 番目の /hello は、web.xml ファイル内のサーブレット マッピング タグにマップされています。

 


エンタープライズ JavaBean アプリケーションの移植と変換

以降の節では、エンタープライズ JavaBean の移植および変換の手順について説明します。

EJB の移植に関する考慮事項

エンタープライズ JavaBean を WebLogic Server 7.0 に移植するときは、以下の事項を考慮してください。

EJB の移植に関する推奨事項

エンタープライズ JavaBean の詳細については、「エンタープライズ JavaBean コンポーネント」および『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。

1.0 EJB を WebLogic Server 4.5.x から WebLogic Server 7.0 に移植する手順

WebLogic Server 3.1.x、4.0.x、および 4.5.x では、EJB 1.0 仕様がサポートされていました。WebLogic Server 4.5 から WebLogic Server 7.0 へ 1.0 形式の EJB を移植するには、次の手順に従います。

  1. EJB 1.0 デプロイメント記述子を EJB 1.1 または EJB 2.0 XML デプロイメント記述子に変換します。この変換は、DDConverter ツールを使用して自動的に行うことができます。

  2. 1 つ前の手順でのデプロイメント記述子の出力と、Bean のクラスを格納する JAR ファイルにデプロイメント記述子をパッケージ化します。

  3. WebLogic Server EJB コンパイラ (ejbc) を実行して JAR ファイルをコンパイルします。ejbc ツールを使用してコンパイルされる EJB は、EJB 1.1 または EJB 2.0 仕様に準拠することが保証されます。

  4. EJB コンテナに EJB をデプロイする前に準拠エラーを修正します。

EJB 1.1 または 2.0 に確実に準拠させるために、EJB 1.0 Bean に対して次の変更を行います。

1.1 EJB を WebLogic Server 5.1 から WebLogic Server 7.0 に移植する手順

WebLogic Server 5.1 デプロイメント記述子では、排他的または読み込み専用の同時実行性オプションだけを使用できます。データベース同時実行性オプションは、WebLogic Server 7.0 の weblogic-ejb-jar.xml ファイルにアップグレードすると指定できるようになります。このオプションの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「eblogic-ejb-jar.xml 文書型定義」にあるデータベース同時実行性に関する情報を参照してください。

WebLogic Server 7.0 CMP デプロイメント記述子では複数の EJB を指定でき、接続プールの代わりに TxDataSource を使用できます。EJB 1.1 CMP で XA が使われているときは、TxDataSource を使用する必要があります。

WebLogic Server 5.1 から WebLogic Server 7.0 へ 1.1 形式の EJB を移植するには、次の手順に従います。

  1. Administration Console を起動します。ホーム ページの [はじめに] メニューから [アプリケーションのインストール] をクリックします。

  2. [参照] ボタンをクリックして移植する JAR ファイルを選択し、[開く]、[Upload] の順にクリックします。これで、Bean が WebLogic Server 7.0 に自動的にデプロイされます。

  3. クライアント ウィンドウで setEnv スクリプトを実行し、開発環境を設定します (詳細については、『WebLogic Server アプリケーションの開発』の「開発環境の構築」を参照)。

  4. 必要なすべてのクライアント クラスをコンパイルします。たとえば、WebLogic Server 7.0 で提供されているサンプルのステートレス セッション Bean の場合は、次のコマンドを使用します。
    javac -d %CLIENTCLASSES% Trader.java TraderHome.java TradeResult.java Client.java

  5. クライアントを実行するには、次のコマンドを入力します。
    java -classpath %CLIENTCLASSES%;%CLASSPATH% examples.ejb.basic.statelessSession.Client

    このコマンドでは、EJB インタフェースがクライアントのクラスパスで参照されることが保証されます。

EJB 1.1 を EJB 2.0 に変換する手順

EJB 1.1 Bean を EJB 2.0 Bean に変換するために、WebLogic Server の DDConverter ユーティリティを使用できます。

WebLogic Server 7.0 では、EJB 2.0 Bean を開発することをお勧めします。既にプロダクション環境で使用されている EJB 1.1 Bean については、2.0 Bean に変換する必要はありません。EJB 1.1 Bean は、WebLogic Server 7.0 でデプロイできます。EJB 1.1 Bean を 2.0 Bean に変換する場合、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「DDConverter」を参照して、この変換を行う方法についての情報を確認してください。

単純な CMP 1.1 Bean を 2.0 Bean に変換するための基本手順を以下に示します。

  1. Bean クラスを抽象クラスにします。EJB 1.1 Bean を Bean の CMP フィールドで宣言します。CMP 2.0 Bean は、各フィールドに対応する抽象メソッドの getXXX および setXXX を使用します。たとえば、EJB 1.1 Bean は public String name を使用します。EJB 2.0 Bean は、public abstract String getName()public abstract void setName(String n) を使用します。この変更を行うと、Bean クラスでのコンテナ管理フィールドの読み込みに getName メソッドが、またコンテナ管理フィールドの更新に setName メソッドが使用されるようになります。

  2. java.util.Enumeration を使用していたすべての CMP 1.1 ファインダは、java.util.Collection を使用する必要があります。CMP 2.0 ファインダは java.util.Enumeration を返すことができません。このことを反映して、コードを変更してください。
    public Enumeration findAllBeans()
    Throws FinderException, RemoteException;

    このコードを次のように変更します。

    public Collection findAllBeans()
    Throws FinderException, RemoteException;

その他の J2EE アプリケーション サーバからの EJB の移植

WebLogic Server 7.0 EJB コンテナには、EJB 1.1 仕様または EJB 2.0 仕様に準拠したすべての EJB をデプロイできます。各 EJB の JAR ファイルには、ejb-jar.xml ファイル、weblogic-ejb-jar.xml デプロイメント記述子、および CMP デプロイメント記述子 (CMP エンティティ Bean を使用する場合) が必要です。WebLogic Server 配布キットの samples¥examples¥ejb11 および samples¥examples¥ejb20 ディレクトリにある WebLogic Server EJB サンプルには、サンプルの weblogic デプロイメント記述子が含まれています。

 


エンタープライズ アプリケーションの作成

エンタープライズ アプリケーションは、拡張子が EAR の JAR ファイルです。EAR ファイルには、アプリケーションのすべての JAR および WAR コンポーネント アーカイブ ファイルと、ひとまとめにされるコンポーネント群を記述する XML 記述子が格納されます。META-INF¥application.xml デプロイメント記述子には、個々の Web モジュールおよび EJB モジュールのエントリのほか、セキュリティ ロールや、データベースなどのアプリケーション リソースを定義する補助エントリがあります。

EnterpriseApplicationStagingDirectory¥
|
+ .jar ファイル
|
+ .war ファイル
|
+META-INF¥-+
|
+ application.xml

EAR ファイルを作成するには、次の手順に従います。

  1. アプリケーションを構成するすべての WAR ファイルと JAR ファイルをアセンブルします。

  2. WAR ファイルと EJB JAR ファイルをステージング ディレクトリにコピーし、アプリケーションの META-INF¥application.xml デプロイメント記述子を作成します。このとき、上の図に示したディレクトリ構造に従います。

    application.xml ファイルには、Sun Microsystems が提供する DTD を使用して、アプリケーションの各コンポーネント用の記述子が定義されます。application.xml ファイルの詳細については、『WebLogic Server アプリケーションの開発』の「アプリケーション デプロイメント記述子の要素」を参照してください。JSP を使用していて、JSP を実行時にコンパイルする場合、WAR ファイルの classes ディレクトリにある Bean のホーム インタフェースとリモート インタフェースが必要です。

  3. ステージング ディレクトリで次のような jar コマンドを実行して、エンタープライズ アーカイブを作成します。
    jar cvf myApp.ear *

  4. コンソールのホーム ページの [はじめに] という見出しの下にある [アプリケーションのインストール] リンクをクリックし、EAR ファイルを domain¥applications ディレクトリに配置します。エンタープライズ アプリケーションの詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのパッケージ化」を参照してください。

 


J2EE クライアント アプリケーションについて

WebLogic Server では、標準の XML デプロイメント記述子を使用して JAR ファイルにパッケージ化された J2EE クライアント アプリケーションがサポートされています。このコンテキストのクライアント アプリケーションは、Web ブラウザではないクライアントです。それらのクライアント アプリケーションは、Remote Method Invocation (RMI) を使用して WebLogic Server に接続する Java クラスです。Java クライアントからは、エンタープライズ JavaBean、JDBC 接続、メッセージングなどのサービスに RMI を使用してアクセスできます。クライアント アプリケーションの種類は、標準入出力を使用する単純なコマンドライン ユーティリティから、Java Swing/AWT クラスを使用して構築される、対話型の高度な GUI アプリケーションまでさまざまです。

WebLogic Server Java クライアントを実行するには、クライアント コンピュータの側にクライアント アプリケーション クラスだけでなく、weblogic_sp.jar ファイル、weblogic.jar ファイル、および WebLogic Server 上のすべての RMI クラスとエンタープライズ Bean に対するリモート インタフェースが必要になります。保守とデプロイメントを簡略化するために、クライアントサイド アプリケーションは、クライアントのクラスパスに追加できる JAR ファイルに weblogic.jar および weblogic_sp.jar ファイルとともにパッケージ化したほうがよいでしょう。weblogic.ClientDeployer コマンドライン ユーティリティは、この仕様に基づいてパッケージ化されたクライアント アプリケーションを実行するためにクライアント コンピュータ上で実行されます。J2EE クライアント アプリケーションの詳細については、『WebLogic Server アプリケーションの開発』の「クライアント アプリケーションのパッケージ化」を参照してください。

 


JMS のアップグレード

WebLogic Server 7.0 は、JavaSoft の JMS 仕様バージョン 1.0.2 をサポートしています。

WebLogic JMS アプリケーションの移植の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」を参照してください。WebLogic Event は非推奨となっており、NO_ACKNOWLEDGE または MULTICAST_NO_ACKNOWLEDGE 配信モードの JMS メッセージで置き換えられています。それぞれの配信モードについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の基礎」で説明されています。

 


Oracle のアップグレード

BEA Systems では Oracle のサポート方針に従い、「動作確認状況」ページの「WebLogic jDriver JDBC ドライバのプラットフォーム サポート」に示されている Oracle のリリースをサポートしています。BEA では現在、バージョン 7.3.4、8.0.4、8.0.5、および 8.1.5 の Oracle Client をサポートしていません。

バージョン 7.3.4 の Oracle Client を使用するには、後方互換性のある oci816_7 共有ライブラリを使用します。既に述べているように、BEA では現在このコンフィグレーションをサポートしていません。

Oracle Client バージョン 9i にアップグレードする方法については、WebLogic jDriver および Oracle データベースのマニュアル、または『WebLogic jDriver for Oracle のインストールと使い方』の「ebLogic jDriver for Oracle のコンフィグレーション」を参照してください。

サポート対象のプラットフォーム、DBMS、およびクライアント ライブラリについては、BEA の「動作確認状況」ページを参照してください。「動作確認状況」ページでは、常に最新の動作確認情報を公開しています。

 


移植とデプロイメントに関するその他の考慮事項

以下の節では、WebLogic Server 7.0 でアプリケーションをデプロイする際に役立つ補足情報を示します。WebLogic Server 7.0 で非推奨となった機能、アップグレード、および重要な変更点を示しています。

注意: WebLogic Server 7.0 ではサンプル データベースとして PointBase 4.2 を使用しており、Cloudscape データベースは同梱されていません。

アプリケーションと管理対象サーバ

デフォルトでは、アプリケーションは管理サーバにデプロイされます。ただし、これはほとんどの場合適切な形態ではありません。管理サーバは管理目的にのみ使用することをお勧めします。Administration Console を使用して新しい管理対象サーバを定義し、それらのサーバにアプリケーションを関連付けてください。詳細については、『ebLogic Server クラスタ ユーザーズ ガイド』および『管理者ガイド』の「ebLogic システム管理の概要」を参照してください。

デプロイメント

デフォルトでは、WebLogic Server バージョン 7.0 は 2 フェーズ デプロイメント モデルを使用します。このデプロイメント モデル、およびバージョン 7.0 のその他のデプロイメント機能の詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server デプロイメント」を参照してください。7.0 のサーバに 4.5 または 5.1 のアプリケーションをデプロイする場合、デプロイメント モデルが指定されていないため、2 フェーズ デプロイメントを使用します。詳細については、『リリース ノート』を参照してください。

プラグイン

プラグインと WebLogic Server 4.5 および 5.1 の間の通信はクリア テキストです。WebLogic Server 7.0 のプラグインは、プラグインとバックエンドの WebLogic Server の間での SSL 通信をサポートしています。

プラグインをアップグレードするには、新しいプラグインを古いプラグインの上に上書きコピーし、IIS、Apache、または iPlanet Web サーバを再起動します。

FileServlet

WebLogic Server 6.1 のサービス パック 2 以降では、FileServlet (Web アプリケーションのデフォルト サーブレット) の動作が変更されています。 現在の FileServlet では、ソース ファイル名を指定する際に SERVLET_PATH も指定できます。 この設定によって、FileServlet を /dir/* などにマップすることで、特定のディレクトリからのファイルのみを明示的に提供できるようになりました。

デフォルト サーブレットの設定」を参照してください。

インターナショナライゼーション (I18N)

このバージョンでは、インターナショナライゼーションとローカライゼーションに関連するいくつかの変更が行われています。

このバージョンでのインターナショナライゼーションの詳細については、『インターナショナライゼーション ガイド』を参照してください。

Java Transaction API (JTA)

JTA の変更点は以下のとおりです。

Java Database Connectivity (JDBC)

JDBC の変更点は以下のとおりです。

JSP

エラー処理

WebLogic Server 5.1 から現在のバージョンに至るまでの間に、JSP include ディレクティブの動作が変更されています。 WebLogic Server 5.1 までのバージョンでは JSP include ディレクティブに存在しないページが含まれる場合、警告レベルのメッセージがログに記録されました。 WebLogic Server 6.0 以降のバージョンでは、そうした場合に「500 Internal Server Error」 が報告され、参照先となる場所に空のファイルを置くことでエラーを回避できます。

null の属性

JSP 仕様の変更により、null のリクエスト属性は空の文字列の代わりに文字列「null」を返すようになりました。 バージョン 6.1 以降の WebLogic Server では、weblogic.xmlprintNulls と呼ばれる新しいフラグがあります。デフォルトではこのフラグは true、すなわち「null」を返す設定になっています。 printNulls を false に設定すると、式の結果が「null」になる場合に文字列「null」ではなく空の文字列が出力されます。

weblogic.xml における printNulls 要素のコンフィグレーションの例を次に示します。

<weblogic-web-app>

<jsp-param>

<param-name>printNulls</param-name>

<param-value>false</param-value>

</jsp-param>

</weblogic-web-app>

JVM

WebLogic Server 7.0 では、サーバのインストール時に JDK 1.3.1_02 の Java 仮想マシン (JVM) がインストールされます。サーバに付属する setenv.sh スクリプトはすべてこの JVM を指しています。動作確認された JVM についての最新情報は、「動作確認状況」ページで公開されています。

RMI

以下のヒントは、以前のバージョンの WebLogic Server で RMI を使用していたユーザが WebLogic Server 7.0 に移植する際のものです。

注意: 詳細については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI の機能とガイドライン」を参照してください。

セキュリティ

新しいセキュリティ アーキテクチャへのアップグレード

WebLogic Server 7.0 は新しいセキュリティ アーキテクチャを備えています。WebLogic Server 4.5 または 5.1 から WebLogic Server 7.0 のセキュリティ機能へのアップグレードは、以下の 2 つの手順で行います。

  1. セキュリティ コンフィグレーションを WebLogic Server 6.x にアップグレードします。

    セキュリティ コンフィグレーションを WebLogic Server 4.5 または 5.1 から WebLogic Server 6.x にアップグレードする方法については、「WebLogic Server 4.5 および 5.1 アプリケーションのバージョン 6.x への移行」の「移行およびデプロイメントの補足事項」の「セキュリティ」を参照してください。

  2. 6.x セキュリティ コンフィグレーションを WebLogic Server 7.0 にアップグレードします。

    詳細については、「WebLogic Server 6.x からバージョン 7.0 へのアップグレード」の「セキュリティのアップグレード」を参照してください。

WebLogic Server 7.0 の新しいセキュリティ アーキテクチャの詳細については、WebLogic Server 7.0 ドキュメントの「セキュリティ」を参照してください。

証明書サーブレットによって生成されるデジタル証明書

WebLogic Server 5.1 の Certificate Request Generator によって作成される CSR を通じて取得したデジタル証明書は、このリリースの WebLogic Server では使用できません。

WebLogic Server 5.1 の Certificate Request Generator を使用して CSR を作成した場合、サーブレットはプライベート キーのパスワードの指定を要求しません。プライベート キーおよび関連のデジタル証明書をこのリリースの WebLogic Server で使用するには、パスワードが必要です。

デジタル証明書のプライベート キー用パスワードを定義するには、JDK keytool を使用します。これで、このリリースの WebLogic Server でデジタル証明書を使えるようになります。keytool を使用してプライベート キーのパスワードを定義する前に、プライベート キーの各行末にある余分な文字を削除することが必要な場合があります。

プライベート キーとデジタル証明書

このリリースの WebLogic Server では、プライベート キーとデジタル証明書でより厳密なチェックが行われます。 既存のプライベート キーとデジタル証明書を使用するためには、次のアップグレード手順を行う必要があります。

  1. プライベート キーが暗号化されている場合は、java utils der2pem コマンドを使用して PEM フォーマットに変換し、ヘッダを次のように修正します。
    ----------BEGIN ENCRYPTED PRIVATE KEY----------
    ...
    -----------END RSA PRIVATE KEY---------------------

    プライベート キーが PEM フォーマットでない場合は、次の例外が送出されます。

    java.lang.Exception:Cannot read private key from file
    C:¥bea700sp5¥user_proects¥mydomain¥privatkey.der
    Make sure password specified in environnment property weblogic.management.pkpassword is valid.

    プライベート キーが暗号化されていない場合は、java utils der.2pem コマンドを使用し、ヘッダを次のように修正します。

    ----------BEGIN RSA PRIVATE KEY----------
    ...
    ----------END RSA PRIVATE KEY----------

  2. デジタル証明書のファイルの最後に余分な行があるか確認します。 証明書ファイルの最後の行は、次のようでなければなりません。
    ----------END CERTIFICATE----------

    余分な行はすべて削除します。

既存のプライベート キーがパスワードで保護されていない場合は、サーバの起動時に weblogic.management.pkpassword 引数を指定する必要はありません。

WebLogic Server Administration Console で SSL プロトコルをコンフィグレーションする際には、[暗号化キーを使用] 属性を使用してプライベート キーがパスワードで暗号化されるかどうかを指定しないことに注意してください。 パスワードがプライベート キーのパスフレーズとして使用されない場合は、この属性は関係ありません。

変換したプライベート キーとデジタル証明書をキー ストアにインポートする場合は、 java utils.ImportPrivateKey を使用します。

セッションの移植

バージョン 6.0 でクッキーの形式が変更されたため、WebLogic Server 6.0 以降では、以前のバージョンのクッキーが認識されません。WebLogic Server では、古い形式のクッキーは無視され、新しいセッションが作成されます。

クッキーのデフォルト名はバージョン 5.1 から変更されています (以前の名前は WebLogicSession)。WebLogic 6.0 以降は、クッキーのデフォルト名は JSESSIONID です。

詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「weblogic.xml デプロイメント記述子の要素」を参照してください。

スタンドアロンの HTML と JSP

WebLogic Server 7.0 で用意されているオリジナルのドメインと、weblogic.properties ファイル コンバータを使用して作成されたすべてのドメインでは、domain¥applications¥DefaultWebApp_myserver ディレクトリが作成されます。このディレクトリには、Web サーバが公開するファイルが格納されます。HTML ファイルと JSP ファイルは、インストールしたアプリケーションとは別にこの場所に配置して公開できます。必要な場合は、画像ファイルなどの相対リンクを処理するために、DefaultWebApp_myserver ディレクトリの内部にサブディレクトリを作成できます。

Web コンポーネント

以下のヒントは、以前のバージョンの WebLogic Server で Web コンポーネントを使用していて、WebLogic Server 7.0 に移植するユーザを対象としています。

WAP アプリケーション

WebLogic Server 7.0 上で WAP (Wireless Application Protocol) アプリケーションを実行するには、Web アプリケーションの web.xml ファイルで、WAP と関連付けられている MIME タイプを指定しなければならなくなりました。 WebLogic Server 5.1 では、デフォルトの MIME タイプは weblogic.propertiesweblogic.httpd.defaultMimeType を使用して設定できます (デフォルト値は「text/plain」)。 WebLogic Server 6.0、WebLogic Server 6.1、および WebLogic Server 7.0 には、デフォルトの mime-type はありません。 web.xml ファイルで拡張子ごとに明示的に mime-type を指定する必要があります。必要な MIME タイプの詳細については、『WebLogic Server Wireless Application 開発プログラマーズ ガイド』を参照してください。web.xml ファイルの作成および編集については、『Web アプリケーションのアセンブルとコンフィグレーション』の「Web アプリケーションのデプロイメント記述子の記述」を参照してください。

web.xml ファイルでの mime-types のコンフィグレーション例を以下に示します。

<web-app>

<mime-mapping>

<extension>tiff</extension>

<mime-type>image/tiff</extension>

</mime-mapping>

<mime-mapping>

<extension>tif</extension>

<mime-type>image/tiff</extension>

</mime-mapping>

</web-app>

書き込み可能な config.xml ファイル

WebLogic Server 7.0 では、バージョン 6.x の config.xml ファイルから読み取られたコンフィグレーション情報が、バージョン 7.0 の情報を取り込んで自動的に更新されます。サーバの複数回の起動の間にこれらの変更を保持するためには、config.xml ファイルを書き込み可能に設定する必要があります。ファイルを書き込み可能にするには、バージョン 6.0 のコンフィグレーションから config.xml ファイルのバックアップ コピーを作成し、ファイル属性を変更します。

XML 7.0 パーサおよびトランスフォーマ

WebLogic Server 7.0 の組み込みのパーサおよびトランスフォーマは、それぞれ Xerces 1.4.4 および Xalan 2.2 に更新されています。以前のバージョンの WebLogic Server に付属していた古いパーサおよびトランスフォーマに対応する API を使用していた場合や、非推奨となったクラス、インタフェース、またはメソッドを使用していた場合、非推奨であることを示すメッセージがアプリケーションで表示されることがあります。

WebLogic Server 7.0 には、WebLogic FastParser も付属します。 これは、WebLogic Web サービスに関連付けられた SOAP および WSDL ファイルなど、中小規模のドキュメントを処理するために特別に設計された高性能の XML パーサです。アプリケーションで中小規模 (要素数が 10,000 個程度まで) の XML ドキュメントを処理することがほとんどの場合、FastParser を使用するように WebLogic Server をコンフィグレーションします。

WebLogic Server 7.0 の配布キットで、未修正版の Xerces パーサおよび Xalan トランスフォーマが WL_HOME¥server¥ext¥xmlx.zip ファイルに含まれなくなりました。

非推奨となった API と機能

以下の API と機能は、将来的に製品から削除される予定なので使用しないでください。

削除された API と機能

以下の API と機能は削除されています。

 

Back to Top Previous Next