この資料には、WebSphere Application Server アドバンスド・シングル・サーバー版 バージョン 4 フィックスパック 6 (4.0.6) およびアドバンスド版 バージョン 4 フィックスパック 6 (4.0.6) の「リリース情報」を記載しています。 WebSphere Application Server バージョン 4 フィックスパック 6 (4.0.6) では TurboLinux on zOS をサポートしない点に注意してください。
これらの情報は、定期的に更新されます。これらのリリース情報の最新版については、IBM WebSphere Application Server インフォセンターのページ ( http://www.ibm.com/software/webservers/appserv/infocenter.html) で確認してください。
この資料では、以下の内容について説明しています。
次の Web サイトには、IBM WebSphere Application Server の前提となる製品がリストされています。
http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html
使用しようとする各製品のライセンス情報をお読みください。これらのライセンス情報は英語でのみ提供されています。
WebSphere Application Server バージョン 4.0.6 は、以下の事項について前提条件となるアップグレードを提供します。
バージョン 4.0.6 の完全なインストール手順は、フィックスパック のインストール・コードに添付された README ファイルに記載されています。バージョン 4.0.6 をインストールする前に、README ファイルをお読みください。フィックスパック は累積パッケージであり、これまでの フィックスパック に含まれていた更新および修正がすべて含まれている点に注意してください。
WebSphere Application Server バージョン 4.0.6 にアップグレードする際に、 DataDirect (旧 Merant) ドライバーを使用してバックエンド・データベースに接続する場合は、これらのドライバーの最新バージョンにアップグレードしてください。詳細については、IBM サポート・サイトを参照してください。
TechNotes データベースには、判明している障害および対処方法についての追加の情報が含まれています。また、 TechNotes データベースには、WebSphere Application Server の資料に記載されているトピックについての補足情報も含まれています。
TechNotes データベースを検索する場合は、TechNotes データベースの Web ページに進み、コンポーネントを選択して、「Go」をクリックしてください。キーワードを使用して、データベースを検索することもできます。
このセクションには、既知の問題とその対処方法についての情報が記載されています。発生した問題がこのセクションに記載されていない場合は、 TechNotes データベースにその問題に関する情報がないか調べてください。
UNIX
AIX
HP-UX
Linux
Solaris オペレーティング環境
Windows2000
Windows NT
WebSphere Application Server フィックスパック のインストール後は、プラグイン構成を再生成してください。作業を開始する前に、ご使用のハードウェアおよびサポートされるソフトウェアの要件が、フィックスパック の前提条件を満たしていることを確認してください。 IBM WebSphere Application Server に必要な前提条件である製品のリストは、http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html にあります。次に、フィックスパック のダウンロード可能ファイルに添付された README ファイルに記載された説明に従って、フィックスパック をインストールします。
構成を再生成するには、以下のステップを実行します。
代替方法として、アドバンスド版またはアドバンスド・シングル・サーバー版のいずれも、コマンド行ユーティリティー GenPluginCfg を実行して、プラグインを再生成することができます。コマンド行ユーティリティーの引き数の情報については、 Windows プラットフォームでは GenPluginCfg.bat と入力し、 UNIX プラットフォームでは GenPluginCfg.sh と入力すると表示されます。詳細については、 WebSphere Application Server バージョン 4.0 インフォセンター を参照してください。
WebSphere Application Server J2EE (Java 2 Enterprise Edition) アプリケーション・ クライアント・ランタイム (launchClient) は、組み込み DataDirect データベース・ドライバーをローカル・クライアント Java Database Connectivity (JDBC) リソースとして使用することをサポートしていません。これを行おうとすると、"License verification failed" エラーが表示されます。
DataDirect ドライバーはライセンスのチェックを実行して、DataDirect ドライバーを使用するための有効なライセンスがあるか確認します。ライセンス・キーは DataDirect によって提供され、このキーは「oemID」フィールドを使用して、データベース接続オブジェクトとして設定する必要があります。 DataDirect はデータベース接続がサーバーに作成されるときに、 WebSphere Application Server ランタイムが使用するライセンス・キーを IBM に提供しています。しかし、クライアントでは、サーバーと同様に、データベース接続ではなく、 javax.sql.DataSource オブジェクトがクライアント・アプリケーションに戻されることが J2EE 仕様によって要求されます。したがって、WebSphere Application Server J2EE アプリケーション・クライアント・ランタイムは、データベース接続オブジェクトの作成または保守を行わず、「 oemID」ライセンス・フィールドを設定できません。クライアント・アプリケーション・コードは、アプリケーション・クライアント・ランタイムによって戻されるデータ・ソース ・オブジェクトから接続オブジェクトを作成し、「 oemID」フィールドを設定する必要があります。 IBM と DataDirect との契約により、 IBM はこの状態でクライアント・アプリケーションが使用可能な形式でライセンス・キーを配布することは禁止されています。クライアント・アプリケーションがデータベースに直接アクセスする必要がある場合は、 DataDirect からクライアント・ライセンスを取得する必要があります。
一般に、WebSphere Application Server は、クライアント・データベース・ドライバーを提供しません。ご使用のクライアント・アプリケーションがデータベースを直接使用する場合は、クライアント・マシン上でデータベース・ドライバーを提供する必要があります。このためには、ご使用のデータベースのベンダーに連絡して、クライアント・データベースのドライバー・コードとライセンスの取得が必要になる場合があります。
クライアント・アプリケーションが、データベースに直接アクセスするのではなく、Enterprise Bean を使用することをお勧めします。 Enterprise Bean を介してデータベースにアクセスする場合は、 WebSphere Application Server で実行されている Enterprise Bean によってデータベース・アクセスが処理されるので、クライアント・マシン上にデータベース・ドライバーは必要ありません。
db2setup コマンドを発行して DB2 インストーラーを始動したきに compat-2001.5.29-0.s390.rpm パッケージがインストールされていないと、セットアップ・コマンドは失敗し、インストーラーが libstdc++-libc6.1-2.so.3 ライブラリーをロードできないことを知らせるエラーが表示されます。
この問題を回避するには、compat-2001.5.29-0.s390.rpm パッケージがインストールされていることを確認してください。このパッケージがインストールされているかどうかは、次のコマンドを発行して確認できます。
rpm -qa | grep compat-2001.5.29-0.
そのパッケージ名がコマンドの出力として戻されない場合、base SuSE SLES 7.0 CD-ROM 上の rpm ファイルを見つけ、インストールしてください。
A. WebSphere Application Server をインストールする前に、次の作業が完了していることを確認してください。
instjdbc.sql スクリプトは、複数のメッセージを生成します。これらのメッセージは、良性でなければなりません。大部分の場合は無視できますが、installation/execution エラーを示すメッセージがないかどうか、出力を調べてください。最後のメッセージは、instjdbc.sql スクリプトが正常に実行されたことを示している必要があります。
B. WebSphere Application Server アドバンスド・シングル・サーバー版の MS SQL Server 用の Type 4 ドライバー・データ・ソースを構成する
名前:serverName
型: java.lang.String
値: servername
注: servername は実際のホスト名です。
「リソース・プロパティー: serverName」パネルで「OK」をクリックしてください。
名前: portNumber
型: java.lang.Integer
値:port_number
注: port_number はポート番号フィールドの実際のポート番号です。1433 は、SQLSERVER のデフォルト portNumber です。
「リソース・プロパティー: portNumber」パネルで「OK」をクリックしてください。
名前: disable2Phase
型: java.lang.Boolean
値: true
「リソース・プロパティー: disable2Phase」パネルで「OK」をクリックしてください。
C. SQL Server を Type 4 ドライバーと共に管理データベースとして使用するように、 WebSphere Application Server アドバンスド版を構成します。
値 com.ibm.ejs.sm.adminServer.dbportNumber = 1433 (デフォルトは「19996」) を変更する。
<variable> <name>jdbcDriver</name> <value>c:/WebSphere/AppServer/lib/base.jar; c:/WebSphere/AppServer/lib/sqlserver.jar; c:/WebSphere/AppServer/lib/util.jar; c:/WebSphere/AppServer/lib/spy.jar </value> </variable>
<variable> <name>jdbcDriver</name> <value>c:/WebSphere/AppServer/lib/msbase.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar/msutil.jar </variable>
D. WebSphere Application Server アドバンスド版の MS SQL Server 用の Type 4 ドライバー・データ・ソースの構成
a.「一般」タブで、以下を実行する。
「一般」タブの下で、
a. JDBC プロバイダーの名前 (たとえば、myDataSource) を入力する。
b. JNDI 名 (たとえば、jdbc/myDataSource) を入力する。
c. 次のカスタム・プロパティーを入力する。
databaseName
portNumber
serverName
user
password
詳細については、『B. WebSphere Application Server アドバンスド・シングル・サーバー版の MS SQL Server 用の Type 4 ドライバー・データ・ソースを構成する』を参照してください。
d.「カスタム・プロパティー」に「
selectMethod」(その値は cursor) を追加する。
e. テスト接続を行う。「接続が正常にテストされました」というメッセージが表示されると、新規データ・ソースが正常に作成されています。
f.「OK」をクリックする。
注: これらの構成メソッドは、ConnectJDBC 3.1 に対し、保管接続として適用可能です。
RMI-IIOP クライアントまたはエンタープライズ・アプリケーション・サーバーが操作中に停止した場合は、次の 2 つの CORBA プロパティーを追加して、アプリケーション・サーバーまたはクライアント・アプリケーションを調整してください。
com.ibm.CORBA.sendTriesCount=n // n is an integer number from 1 to JAVA Max allowed integer number // default value of n is 5 // n means n number of attempts // by setting this to 3, it will make maximum of 3 attempts on each request. // if all n attempts are failed on that particular request, error or exception // will be thrown. com.ibm.CORBA.sendTriesDelay=n // n is an integer number from 0 to JAVA Max allowed integer number // default value of n is 0 // n means n is millisecond // by setting this to 1000, it will make 1 second sleep time in between // each attempt
注: 上記の 2 つのプロパティーを使用すると、わずかにパフォーマンスに影響することがあります。しかし、オブジェクト・リクエスト・ブローカー (ORB) はこれらのプロパティーを使用してクライアント・サイドの IBM Software Development Kit から断続的に入出力例外がスローされるのを回避しているため、このパフォーマンスへの影響は避けられません。さらに、これらのプロパティーは com.ibm.CORBA.requestRetriesCount
プロパティーおよび com.ibm.CORBA.requestRetriesDelay プロパティーとは異なります。クライアント・アプリケーションとアプリケーション・サーバーを調整するために、この 4 つすべてのプロパティーの使用が必要な場合があります。
WebSphere Application Server アドバンスド版で処理中ロギングを使用可能にする (Defect 144808)
2 フェーズ・コミットメント・トランザクションを多く使用する WebSphere Application Server アドバンスド版のスループットを改善することができます。アプリケーション・サーバーが、デフォルトの管理サーバーを介したロギングではなく、処理中トランザクション・ロギングを使用するように構成します。処理中トランザクション・ロギングを使用可能にするには、特定のアプリケーション・サーバーの Java 仮想マシン (JVM) 設定に対してシステム・プロパティー WAS_TRANSACTION_LOGSPEC を設定します。システム・プロパティーの値は、コンマで区切った一対のファイルに設定します。この 2 つのファイルがサーバー・トランザクション・ログ (たとえば、/WebSphere/AppServer/tranlog/server1log1,/WebSphere/AppServer/tranlog/server1log2) に使用されます。
AIX
Informix IDS_2000 では、AIX 4.3.3 プラットフォーム上で libc_r.a 問題が発生する (108882.RN)
Informix IDS_2000 では、このソフトウェアが問題なくインストールされた場合でも、インストール後に AIX 4.3.3 プラットフォームでロード libc_r.a 問題が起こります。 oninit -ivy、onstat -l、または onmode など、Informix コマンドを実行すると、エラー・メッセージを受け取ります。
エラー・メッセージを受け取らないためには、次のいずれかを実行してください。
AIX
AIX プラットフォームで APAR IY19277 を適用した後、Netscape ブラウザーをアップグレードする (108934)
WebSphere Application Server とすべての前提条件ソフトウェアを AIX プラットフォームにインストールした後に、Netscape Communicator 4.73 (またはそれ以降) が始動しないことがあります。次のエラー・メッセージはこの障害を示しています。
プログラム /afs/torolab.ibm.com/common/progs/netscape47/netscape_aix4 をロードできません。 /usr/lib/libpthreads.a(shr.o) のためのシンボル解決が失敗しました。理由は以下のとおりです。 (Could not load program /afs/torolab.ibm.com/common/progs/netscape47/netscape_aix4: Symbol resolution failed for /usr/lib/libpthreads.a(shr.o) because:) シンボル thread_unlock (番号 121) が従属モジュール /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o) からエクスポートされていません。 (Symbol thread_unlock (number 121) is not exported from dependent module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o).) シンボル thread_waitlock (番号 122) が従属モジュール /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o) からエクスポートされていません。 (Symbol thread_waitlock (number 122) is not exported from dependent module /afs/torolab.ibm.com/common/progs/netscape47/lib433/libc_r.a(shr.o).)
このエラーは、Netscape Communicator V4 が、他の共用 AIX ライブラリーと同期されたままでなければならない libc.a の専用コピーを使用するために発生します。システムに AIX 更新を適用する場合は、Netscape Communicator が使用する libc.a のコピーを更新してください。
以下の URL から更新済み版の libc.a をダウンロードして、Netscape のインストール・ディレクトリー内にあるこのファイルを置き換えることができます。
ftp://aix.software.ibm.com/aix/efixes/netscape/aix433_libc/
libc.a をダウンロードして、既存の Netscape システム内の libc.a を置き換えるためには、(README ファイルの) 説明を読んでそれに従ってください。
AFS または DFS のロケーションから Netscape を実行した場合、Netscape のディレクトリーへの書き込み許可が無いため、自分でこれを実行できない場合があります。そのような場合には、AFS または DFS 管理者に連絡してください。
代替方法として、この問題を訂正する Netscape の新規バージョン (4.76i) をダウンロードすることができます。このバージョンをローカル・マシンにダウンロードしてインストールできます。ダウンロードの場所は、次のとおりです。
ftp://aix.software.ibm.com/aix/efixes/netscape/aix43_installp/
Sun Microsystems Enterprise JavaBeans 仕様、V 1.1 の 18.3.2 の項に次のような記載があります。「 Enterprise Bean のホームおよびリモート・インターフェースは、Java RMI のリモート・インターフェースです (The enterprise bean's home and remote interfaces are remote interfaces for Java RMI)」。コンテナーは、引き数を渡すためのセマンティクスが Java RMI に準拠していることを確認する必要があります。非リモート・オブジェクトを、値によって受け渡すことはできません。つまり、呼び出し側の Enterprise Bean と呼び出し先の Enterprise Bean が同じ Java 仮想マシン (JVM) 内で連結されている場合、この EJB コンテナーは EJB 呼び出し間の参照によって非リモート・オブジェクトを渡すことはできません。もし渡した場合は、複数の Bean が 1 つの Java オブジェクトの状態を共用することになり、Enterprise Bean のセマンティクスが破壊されます。
この情報は、Enterprise Bean に対して pass-by-reference オプションを使用することは、意図的な EJB 仕様違反であるという結論を下しています。さらに、このオプションを選択する場合、注意しなければいけないコーディング上の考慮事項があります。EJB メソッドまたは EJB ホーム・メソッドに渡されるオブジェクト参照はコピーされないため、破壊が発生する可能性があります。以下の例を参照してください。
Iterator iterator = collection.iterator(); MyPrimaryKey pk = new MyPrimaryKey(); while (iterator.hasNext()) { pk.id = (String) iterator.next(); MyEJB myEJB = myEJBHome.findByPrimaryKey(pk); }
このコード・サンプルでは、同じ MyPrimaryKey オブジェクトに対する参照が、毎回異なる ID 値を使用して WebSphere Application Server に渡されます。 pass-by-reference オプションを使用可能にしてこのコードが実行されると、複数の Enterprise Bean が同じ MyPrimaryKey オブジェクトを参照しているため、 WebSphere Application Server 内で問題が発生します。pass-by-reference モードで実行しているときに WebSphere Application Server バージョン 4.0.5 でこの問題が発生するのを回避するためには、さらにシステム・プロパティー com.ibm.websphere.ejbcontainer.allowPrimaryKeyMutation を true に設定する必要があります。これにより、 EJB コンテナーは PrimaryKey オブジェクトのローカル・コピーを作成します。ただし、pass-by-reference オプションを設定した場合のパフォーマンス上の利点が、これにより若干失われることになります。
これは、pass-by-reference オプションの使用により発生する可能性のある問題の一例です。一般に、EJB メソッドまたは EJB ホーム・メソッドにパラメーターとしてオブジェクト参照を渡すアプリケーション・コードは、そのオブジェクト参照を渡すことによって保全性やその他の問題が発生しないかどうかを判別するために綿密に検査する必要があります。
マシン上にプラグインと Web サーバーのみがインストールされている場合、フィックスパック をインストールするマシンに IBM Software Development Kit をインストールしてください。 WebSphere Application Server バージョン 4.0 はプラグインをインストールするときに、 IBM Software Development Kit をインストールしません。フィックスパック のインストールでは Java コードを使用するため、IBM Software Development Kit が必要になります。
フィックスパック 4 をインストールするときに、WebSphere Application Server をアップグレードする場合は、IBM Software Development Kit のレベルもアップグレードする必要があります。 IBM Software Development Kit のレベルをアップグレードするには、「 はい」を選択してください。
ファイルのバックアップ中に WebSphere Application Server フィックスパック 5 のインストールに割り込みを行うと、 backup_jar ファイルが破壊され、それによってアンインストールが失敗することがあります。インストールを続行する場合は、バックアップ JAR ファイルが保管される場所に特に注意してください。ユーザー独自のディレクトリーを指定することもできますが、最も一般的なデフォルト・ロケーションは、<was_root> ディレクトリーと、インストール・スクリプトを実行しているディレクトリーの 2 つです。 WebSphere Application Server の更新をインストールしている場合、デフォルト・ディレクトリーは <was_root> です。更新をインストールしない場合のデフォルト・ディレクトリーは、インストール・スクリプトの置かれたディレクトリーです。破壊されたバックアップ JAR ファイルを、そのディレクトリーにある JAR ファイルと置換してください。フィックスパック のバックアウトまたはアンインストールが必要な場合は、バックアウトしようとしているコンポーネントを基に、有効なバックアップ JAR ファイルが 1 つのディレクトリーに存在していることを確認してください。
注: uninstall_ptf_5.sh または uninstall_ptf_5.bat スクリプトを <was_root> ディレクトリーから実行した場合、特に指定しないかぎり、アンインストールはデフォルトによりそのディレクトリーにあるバックアップ JAR ファイルを使用します。バックアップ JAR ファイル名の例としては、 ihs_ptf_5_backup.jar、jdk_ptf_5_backup.jar、J2C_ptf_5_backup.jar、および was40_ae_ptf_5_backup.jar などがあります。
インストール方法の詳細については、README ファイルを参照してください。
CSD3 を MQSeries 5.2 に適用する必要があります。 WebSphere Application Server の管理サーバーの実行中に MQSeries キュー・マネージャーが停止した場合、システムをリブートせずに MQSeries キュー・マネージャーを再始動することができます。ただし、管理サーバーのサイクルが必要になることがあります。
SQL Server を WebSphere Application Server 管理リポジトリーとして使用する場合は、 SQL Server に WebSphere Application Server (WAS) データベースがあることを確認してください。 SQL サーバーに Enterprise Manager を作成するには、次のステップを実行してください。
注: 上記の情報は、インフォセンター項目の『6.6.46: WebSphere 管理サーバーの管理』と『6.6.14.5: 特定データベースに対する追加の管理タスク』にも適用されます。
インストール中に、バックエンド・データベースとして Informix を選択し、さらにリモート・データベース・オプションを選択すると、インストール・プログラム はリモート・データベース・オプションを指定して Informix データベースを構成することができます。 Informix を手動で構成するには、インストールの完了後、admin.config ファイルに以下のプロパティーを設定してください。
com.ibm.ejs.sm.adminServer.dbifxIFXHOST=remote_host_name
WebSphere Application Server バージョン 3.5.3 またはバージョン 3.5.4 で Java Naming and Directory Interface (JNDI) クライアントを使用してバージョン 4.0.x ネーム・サーバーにアクセスしたい場合は、バージョン 3.5.x 製品 に fix PQ51387 を適用する必要があります。この fix は、 http://www.ibm.com/software/webservers/appserv/support.html から入手できます。
README の指示に従って、WebSphere Application Server バージョン 3.5.x の ujc.jar ファイルと ns.jar ファイルを更新してください。
以前のバージョンの WebSphere Application Server アドバンスド・シングル・サーバー版がインストールされているのと同じディレクトリーに、WebSphere Application Server アドバンスド版をインストールおよびマイグレーションした場合、アドバンスド・シングル・サーバー版のシステムは、それ以降無効になります。アンインストール・プログラムは実行しないでください。実行した場合、新しくインストールしたアドバンスド版がアンインストールされます。
さらに、以前の WebSphere Application Server アドバンスド・シングル・サーバー版がインストールされているのと同じディレクトリーに WebSphere Application Server アドバンスド版をインストールおよびマイグレーションすると、アドバンスド・シングル・サーバー版のプロパティー・ファイルが失われます。プロパティー・ファイルを手動でマイグレーションする予定の場合は、アドバンスド版をインストールする前にアドバンスド・シングル・サーバー版のプロパティー・ファイルのバックアップを取っておく必要があります。
Lightweight Third Party Authentication (LTPA) および Lightweight Directory Access Protocol (LDAP) クラスターを使用しているときに認証が失敗したり非常に遅い場合は、次の 2 つの構成を実行するか、またはそのうちのいずれかを選択してください。
注: LDAP クラスターは複数の LDAP サーバーとして定義されていますが、 Network Dispatcher またはインターネット・プロトコル (IP) スプレイヤーを使用しているため、 1 つの LDAP サーバーのように見える点に注意してください。
注意: 時間制限が短すぎると、検索が完了する前に終了される可能性があります。
ネットワーク・リソースを利用する フィックスパック のインストールは、ローカル・リソースを使用するインストールよりも、実行にかなり時間がかかる可能性があります。
最高速度を確保するためには、次のファイルおよびディレクトリーがローカル・リソースから利用可能であることを確認してください。
これらの値を設定する方法については、使用法とヘルプ・テキストを参照してください。インストール・スクリプトとアンインストール・スクリプト両方の使用法情報があります。使用法情報を表示するには、-usage コマンド行オプションを使用してください。包括的ヘルプを表示するには、-help コマンド行オプションを使用してください。
バージョン 4.0.3 より前のバージョンの WebSphere Application Server で実行されていたアプリケーションは、J2EE (Java 2 Enterprise Edition) タグ・シーケンス標準についてチェックしませんでした (これらのアプリケーションは機能しなかったり、変更が必要な場合があります)。現在はタグ・シーケンスの検証があり、現行リリースでは標準がサポートされています。
WebSphere Application Server のエレメント・タイプ・タグ・シーケンスは、 name、tag class、teiclass、body content、information、および attribute* という要件に一致している必要があります。
WebSphere Application Server バージョン 4.0.3 以上用の JavaServer Pages page (JSP) エレメント・タグ (name、tag class、teiclass、body content、information、attribute*) を使用して作成されたアプリケーションは、URL http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd に定義されている標準に従う必要があります。
マシン上にプラグインしかインストールされていない場合は、フィックスパック をインストールするときに「はい」を選択して WebSphere Application Server をアップグレードする必要があります。 WebSphere Application Server を更新するときに、新しいプラグイン・ファイルがインストールされます。追加ファイルが、<WAS_UPDATE_HOME> ディレクトリーの下にインストールされることがあります。ただし、これらのファイルで問題が発生することはありません。
B. WebSphere Application Server アドバンスド・シングル・サーバー版の MS SQL Server 用の Type 4 ドライバー・データ・ソースを構成する
名前:serverName
型: java.lang.String
値: servername
注: servername は実際のホスト名です。
「リソース・プロパティー: serverName」パネルで「OK」をクリックしてください。
名前: portNumber
型: java.lang.Integer
値:port_number
注: port_number はポート番号フィールドの実際のポート番号です。1433 は、SQLSERVER のデフォルト portNumber です。
「リソース・プロパティー: portNumber」パネルで「OK」をクリックしてください。
名前: disable2Phase
型: java.lang.Boolean
値: true
「リソース・プロパティー: disable2Phase」パネルで「OK」をクリックしてください。
C. SQL Server を Type 4 ドライバーと共に管理データベースとして使用するように、 WebSphere Application Server アドバンスド版を構成します。
値 com.ibm.ejs.sm.adminServer.dbportNumber = 1433 (デフォルトは「19996」) を変更する。
<variable> <name>jdbcDriver</name> <value>c:/WebSphere/AppServer/lib/base.jar; c:/WebSphere/AppServer/lib/sqlserver.jar; c:/WebSphere/AppServer/lib/util.jar; c:/WebSphere/AppServer/lib/spy.jar </value> </variable>
<variable> <name>jdbcDriver</name> <value>c:/WebSphere/AppServer/lib/msbase.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar;c:/WebSphere/AppServer/lib/mssqlserver.jar/msutil.jar </variable>
D. WebSphere Application Server アドバンスド版の MS SQL Server 用の Type 4 ドライバー・データ・ソースの構成
a.「一般」タブで、以下を実行する。
「一般」タブの下で、
a. JDBC プロバイダーの名前 (たとえば、myDataSource) を入力する。
b. JNDI 名 (たとえば、jdbc/myDataSource) を入力する。
c. 次のカスタム・プロパティーを入力する。
databaseName
portNumber
serverName
user
password
詳細については、『B. WebSphere Application Server アドバンスド・シングル・サーバー版の MS SQL Server 用の Type 4 ドライバー・データ・ソースを構成する』を参照してください。
d.「カスタム・プロパティー」に「
selectMethod」(その値は cursor) を追加する。
e. テスト接続を行う。「接続が正常にテストされました」というメッセージが表示されると、新規データ・ソースが正常に作成されています。
f.「OK」をクリックする。
注: これらの構成メソッドは、ConnectJDBC 3.1 に対し、保管接続として適用可能です。
一部のインストールでは、インストール済みのエンタープライズ・アプリケーションのディレクトリー、<WAS_ROOT>/installedApps にシンボリック・リンクが使用されます。アプリケーションの除去中、それを指定するためのディレクティブが追加されます。ファイルを再帰的に削除する場合は、シンボリック・リンクをこの後に指定します。新しいディレクティブは、 com.ibm.ejs.adminServer.recursiveDeleteSymLink=true です。
注: このプロパティーを活動化する前に、これらのリンクが、エンタープライズ・アプリケーション・ディレクトリーのシンボリック・リンクを使用しているときに除去した場合に、システムに害を及ぼす可能性のあるディレクトリーを指していないことを確認してください。
サポートされている唯一のインターオペラビリティー構成は、 WebSphere Application Server バージョン 4.0.4 管理クライアントを使用したバージョン 4.0.5 管理サーバーの管理です。マルチノード WebSphere 環境と EAR ファイル配置で、バージョンの異なるクライアントとサーバーを混在させた場合の影響には次のようなものがあります。
このサポートの主な理由は、大規模の顧客に関連したインクリメンタル・マイグレーションにあります。このインクリメンタル・マイグレーションは、ある フィックスパック・レベルの管理クライアントが別の フィックスパック・レベルの管理サーバーと対話する状況を処理するものです。
推奨構成はやはり、管理クライアントと管理サーバーの両方に WebSphere Application Server バージョン 4.0.5 を使用することです。
admin.config ファイルに新規プロパティーを適用して、汎用サーバー NodeStartState を構成することができます。新規プロパティーは com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = [Current|Running|Stopped] です。
新規プロパティーを適用するには、次のテキストを admin.config ファイルに追加します。
# NodeStartState of generic servers: [Current|Running|Stopped]
com.ibm.ejs.sm.adminServer.GenericServerNodeStartState = (NodeStartState)
NodeStartState オプション:
Current: 各汎用サーバーは、ノードの始動前の状態である。
Running: 各汎用サーバーは、最終状態に関係なく、実行状態である。
Stopped: 各汎用サーバーは、最終状態に関係なく、停止状態である。
新規プロパティーは、全体として汎用サーバーに適用されます。指定されたプロパティーは、ノード上に作成されたすべての汎用サーバーに影響します。このプロパティーは、他のノード上に作成された汎用サーバーには影響しません。
WebSphere Application Server アドバンスド・シングル・サーバー版に用意されている Web ベースの管理コンソールを使用してプラグインを生成する際に、コマンド行スクリプト GenPluginCfg.[sh/bat] により提供されるプラグイン構成を再生成する場合と同じ構成オプションを使用することができます。
次に示すのは、コマンド行ユーティリティーで提供されるパラメーターのリストです。
IBM WebSphere Application Server Advanced Single Server Edition, Release 4.0 Web Server Plug-in Configuration Generator Copyright IBM Corp., 1997-2001 Required Argument Missing: -configFile Usage: Use one of the following commands java com.ibm.websphere.plugincfg.tool.SEGeneratePluginCfg -configFile <server configuration file> [-outputFile <directory to write the config file to>] [-nodeName <name of node>] [-serverName <name of server>]
-outputFile オプションを使用すると、WebSphere Application Server の複数インスタンスで plugin-cfg.xml ファイルを出力するディレクトリーを指示することができます。現時点では、Web ベースの管理コンソールを使用して plugin-cfg.xml ファイルを再生成する場合には、このオプションは存在しません。
WebSphere Application Server には、この振る舞いを可能にするために、ブラウザーによるプラグインの再生成時に参照される新しい PathMapEntry が用意されています。標準インストールを行う場合は <WAS_ROOT> /config/server-cfg.xml ファイルを参照してください。この変更は、使用する構成インストールによって異なります。次に示すのは、新規エントリー PLUGIN_CFG_ROOT の例です。
<entries xmi:id='PathMapEntry_7' symbolicName='PLUGIN_CFG_ROOT' path='C:\temp' description='The filesystem path to write the plugin-cfg.xml'/>
HP-UX
iPlanet Web server の一部のインストールでは SHLIB_PATH 変数を手動で設定する (108778.RN)
HP-UX マシンに iPlanet Web サーバーをインストールする場合、 Secure Sockets Layer (SSL) 用に構成されたプラグインを使用して iPlanet Web サーバーを始動する前に、手動で SHLIB_PATH 変数を /usr/lib に設定する必要があることがあります。たとえば、Korn シェルでは、 iPlanet Web サーバーを始動するためのコマンドを呼び出す前に、次のコマンドを発行します。
export SHLIB_PATH=/usr/libUNIX プラットフォームを使用している場合は、オプションとして startupServer.sh スクリプトを使用可能にして、Nanny プロセスと管理サーバー・プロセスの追加モニターを実行することができます。この機能を使用可能にするためには、次のプロパティーを admin.config ファイルに追加してください。
com.ibm.ejs.sm.adminServer.forceReconnect=true
このプロパティーを設定すると、追加のモニターが活動化されます。このプロパティーを (true のみでなく) 任意の値に設定しても、管理サーバーは、実行中のアプリケーション・サーバーを常に再始動する代わりに、それらのサーバーへの接続を常に試行します。このプロパティーが true に設定されていると、startupServer.sh スクリプトは以下のことを行います。
このプロパティーが設定されていないと、Nanny プロセスによって再始動された場合か、adminserver.sh スクリプトによって始動された場合にのみ、管理サーバーは実行中のアプリケーション・サーバーへの再接続を試行します。
単一システム上で WebSphere Application Server の複数のインスタンスを実行している場合は、com.ibm.ejs.sm.adminServer.forceReconnect プロパティーを設定しないでください。
注: この新機能は HP-UX 11 では使用できません。
UNIX
UNIX プラットフォーム上で wscp コマンドを実行後、ログ・ファイルが開かない (110363.RN)
管理コンポーネントのみをインストールした場合は、次のファイルを編集して、$(WASROOT) を WebSphere Application Server のホーム・ディレクトリーに置き換えてください。
install_root/properties/sas.client.props。このファイルで次の行を見付けてください。
com.ibm.CORBA.securityTraceOutput=$(WASROOT)/logs/sas.client.log
AIX
AIX 上のファイルがインストールされるが、チェックサム・エラーが発生する (XPQ35815.RN)
WebSphere Application Server を AIX マシンにインストールして installp コマンドを実行すると、一部のインストール済みファイルからエラーを受け取ります。これらのエラーは製品のインストール、実行、またはアンインストールには影響ありません。
HP-UX
HP マシン上でリポジトリーとして Sybase を使用する (Defect 122525.RN)
Sybase をリポジトリーとして使用することは WebSphere Application Server バージョン 4.0.1 ではサポートされていませんが、WebSphere Application Server バージョン 4.0.5 ではサポートされています。 Sybase リポジトリーを使用して WebSphere Application Server を始動する前に、いくつかのファイルを変更してください。
この問題を回避するには、以下のステップを実行してください。
その後、インストールを続行してください。
admin.config setupCmdLine.sh startupServer.sh.
そして、<was_root>/properties ディレクトリー内の次の 1 つのファイルを変更します。
initial_setup.config
以下の指示に従って、ファイルを変更してください。
a. admin.config ファイル
com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs= で始まる行末に進み、Java Database Connectivity (JDBC) ライブラリーのディレクトリーを変更します。 /opt/WebSphere/AppServer/lib/ext のすぐ後に、WebSphere Application Server が必要なクラスの検出に使用する JDBC ライブラリーがあります。 Sybase ディレクトリーを指定します (たとえば、/opt/sybase12/jConnect-5_2/classes/jconn2.jar)。
com.ibm.ejs.sm.adminServer.dbdataSourceClassName= で始まる行には、com.sybase.jdbc2.jdbc.SybConnectionPoolDataSource を指定する必要があります。この情報には、大文字小文字の区別があることに注意してください。データベースとして DB2 を選択した場合、クラス名内の com は、大文字になります。必ず、それを Sybase 用に小文字に変更してください。
com.ibm.ejs.sm.adminServer.dbserverName には、データベースがインストールされるホストを選択します。
com.ibm.ejs.sm.adminServer.dbportNumber には、データベース用のポートを選択します。 Sybase 用のデフォルトは、4100 です。
b. setupCmdLine.sh ファイル
次のように環境変数を変更します。
DBDRIVER_JARS=/opt/sybase12/jConnect-5_2/classes/jconn2.jar DBDRIVER_PATH=/opt/sybase12 DBTYPE=Sybase DB_INSTANCE_HOME=/opt/sybase12
c. startupServer.sh ファイル
スクリプトがどのデータベース・タイプが指定されているかをチェックするために調べるセクションに次の行を追加します。
elif [ "${DB_TYPE}" = "Sybase"]
then
{ DB_CLASSPATH=$DB_INSTANCE_HOME/jConnect-5_2/classes/jconn2.jar }
d. initial_setup.config ファイル
このファイルには、<config-file> で始まるいくつかの行があります。これらの行はデータベースに特定のため、いくつかはコメント化されています。インストールに使用したデータベース・タイプに特定の行をコメント化し、Sybase の行のコメントを外してください。Sybase の行は、次のようになります。 <config-file>/opt/WebSphere/AppServer/bin/ImportSamplesConfigSybase.xml</config-file>
XML の残りは、次のようになります。
<variable> <name>XMLConfigDTDLocation</name> <value>/opt/WebSphere/AppServer/bin</value> </variable> <variable> <name>serverName</name> <value>Default Server</value> </variable> <variable> <name>dbPrefix</name> <value></value> </variable> <variable> <name>jdbcDriver</name> </opt/sybase12/jconnect-5_2/classes/jconn2.jar> </variable> <variable> <name>repositoryDBName</name> <value>WAS</value> </variable> <variable> <name>pslash</name> <value>$(PSLASH)</value> </variable>
次のようなエラーを受け取る場合があります。
An error occurred converting UNICODE to the charset used by the server. Error Message: java.io.CharConversionException: java.io.Unsupported Encoding Exception : hp-roman8
この場合、WebSphere Application Server に使用させたい charset を設定する必要があります。 <install_root>/bin/admin.config ディレクトリーを変更して、com.ibm.ejs.sm.adminServer.dbconnectionProperties=CHARSET=utf8; CHARSET_CONVERTER_CLASS=com.sybase.jdbc2.utils.TruncationConverter; を追加します。ここで、utf8 は指定したい文字セットです。この設定はすべて 1 行に指定し、ここに示されているように 2 行に分割しないでください。
HP-UX
KC_PARAM_DEFAULT パラメーターが 65535 でない場合、DB2 が動作しない (114435、116016.RN)
WebSphere Application Server でサポートされるソフトウェアのデータベース ( http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html) の記載にあるように、HP-UX 11.11 (または 11i) システムでは、 WebSphere Application Server で DB2 を正しく実行するには、パッチ (ファイル・セット) HWEnable11i_11.11.depot および PHKL_25368 が必要です。ただし、このファイル・セットをインストールしても、msgmax カーネル・パラメーターの値はシステム・リブート後には元の値の 8192 に戻ってしまう可能性があります。値が元に戻ると、DB2 は正しく動作しません。この値は 65535 でなければなりません。
HP-UX
Secure Sockets Layer 対応のプラグイン・サポート (Defect 105995.RN.1, 150859)
Secure Sockets Layer (SSL) 対応のプラグインは、Apache HTTP Server 製品のインストールされた HP-UX ではサポートされていません。
この組み合わせ以外では、SSL 対応プラグインは、 AIX、HP、Solaris オペレーティング環境、Windows NT、Windows 2000、および Linux プラットフォームにおいて、IBM HTTP Server、Apache HTTP Server、 Microsoft IIS、Lotus Domino、および iPlanet Web サーバーとの使用がサポートされています。
Secure Sockets Layer (SSL) 用に構成されているプラグインを用いて RedHat 7.1 Linux システム上で Apache HTTP Server を稼働している場合は、Apache を始動する前に LD_PRELOAD 環境変数を下記の値に設定する必要があります。
/usr/lib/libstdc++-libc6.1-1.so.2
たとえば、Korn シェルを使用している場合、Apache HTTP Server を始動する前に下記を入力します。
export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
Linux
Trade 2 アプリケーションを使用する場合、リモート・マシン上で DB2 データベースを設定する (132820.RN)
Linux カーネルの制限により、ビジネス・アプリケーションを使用するときに stderr.log ファイルでメモリー不足エラーが生成されるのを回避するために、アプリケーション・サーバー・データベースをリモート・データベース・サーバー上に作成してください (たとえば、DB2 の Trade 2 Application)。可能な場合、より良い長時間実行環境を得るため、WebSphere Application Server 管理サーバーをリモート・データベース・サーバー上に作成してください。
DB2 が正常に動作し、WebSphere Application Server 上の Trade アプリケーションに接続できるように、追加の構成ステップを実行してください。データベースのリモート使用の説明については、 WebSphere Application Server バージョン 4.0 の インフォセンターの項目、『 TCP/IP を使用してリモートに WebSphere に接続するようにデータベース・マネージャーを構成する』と『 Linux 上で DB2 UDB を構成する』を参照してください。
「Choose Location」パネルに従って WebSphere Application Server アドバンスド版 バージョン 4.0.x をドイツ語の SuSE Linux 7.3 プラットフォームにインストールするときに、インストール・ウィザードが "datei nicht" というメッセージを表示して、インストールが続行できなくなります。
この問題を回避するためには、ドイツ語ではなく、英語のロケールを使用して、WebSphere Application Server アドバンスド版、バージョン 4.0.x をインストールしてください。インストールが完了したら、コマンド export LC_ALL=de_DE と export LANG=de_DE を発行して、ドイツ語のロケールに変更してください。
メッセージ・ブローカーは、Linux プラットフォーム上では WebSphere Application Server MQSeries SuSE V7.2 の始動を完了しません。strmqbrk -m <Queue Manager> コマンドを実行した場合、決して完了しません。また、このコマンドは CRL-C を使用して割り込みできません。 dspmqbrk コマンドを使用してメッセージ・ブローカーの状況をチェックした場合、結果は次のようになります。
"MQSeries message broker for queue manager <Queue Manager> starting."
デフォルトにより、Linux SuSE 7.2 には、MQSeries に必要なグループ ID nobody がありません。前述の問題が発生した場合は、すべての MQSeries プロセスを停止して、グループ ID nobody を作成してください。それにより、メッセージ・ブローカーを始動することができます。
Linux
SuSE 上で Netscape バージョン 4.7.6 を構成する (104266)
SuSE バージョン 7.1 および Netscape バージョン 4.7.6 を含む WebSphere Application Server アドバンスド・シングル・サーバー版をインストールする場合は、管理コンソールの左側にあるツリー表示が正しく表示されるようにするため、以下のように Netscape 構成値を変更しなければなりません。
http://your_machine_name:9090/admin
から管理コンソールを開始する。
Secure Sockets Layer (SSL) 用に構成されているプラグインを用いて RedHat 7.1 Linux システム上で Apache HTTP Server を稼働している場合は、Apache を始動する前に LD_PRELOAD 環境変数を下記の値に設定する必要があります。
/usr/lib/libstdc++-libc6.1-1.so.2
たとえば、Korn シェルを使用している場合、Apache HTTP Server を始動する前に下記を入力します。
export LD_PRELOAD=/usr/lib/libstdc++-libc6.1-1.so.2
Linux
Oracle 8i に Java Database Connectivity 2.0 ドライバー classes12.zip がない (115823, 115823.RN)
Oracle 8i の配布では、Linux プラットフォーム用の Java Database Connectivity (JDBC) 2.0 ドライバー・ファイル classes12.zip を提供していません。予備手段として、Solaris classes12.zip ファイルを以下の Oracle Web サイトからダウンロードしてください。
注: 使用できるのは Java シン・ドライバーのみで、OCI (シック) ドライバーを使用しようとするとエラーになります。この問題に関して詳しくは、Oracle のテクニカル・サポートに問い合わせてください。
Linux
Linux ノード間での通信問題 (Defect 148581)
一部の Linux インストールでは、WebSphere Application Server バージョン 4.0.x で、ノード間の通信に困難が生じることがあります。特に、このノード間通信の困難は、管理コンソールによるリモート WebSphere 管理サーバーの制御能力に影響します。
これは一部の Linux 配布版で、ホスト名が外部インターネット・プロトコル (IP) アドレスではなく、ループバック・ポートにマップするように、/etc/hosts ファイルが構成されていることが原因です。
ノード間の通信問題が発生した場合は、ホスト名を正しい外部 IP アドレスにマップするように、/etc/hosts ファイルを更新してください。たとえば、次のように指定します。
127.0.0.1 localhost 9.x.x.x yourhostname.yourdomain yourhostname
Linux
RedHat 上で WebSphere Application Server バージョン 4.0.5 を適用するときに、カーネルと glibc の値を更新する (Defect 119386.RN)
2.4.10 より前のカーネルにおける Linux カーネルの欠陥により、IBM Software Development Kit の浮動スタックのサポートは SMP マシン上では正しく機能しません。 WebSphere Application Server バージョン 4.0.5 を SMP マシン上で適用するには、カーネルが >= 2.4.10 であり、glibc が = 2.2.4 である必要があります。カーネルおよび glibc のアップグレードについては、配布プロバイダーに問い合わせてください。
RedHat では、ユーザーは環境変数 LD_ASSUME_KERNEL=2.2.5 をエクスポートすることにより、LD_ASSUME_KERNAL=2.2.5 を設定することができます。この変数により、RedHat による浮動スタック・サポートを使用不可にする変更が使用可能になり、それにより IBM Software Development Kit がデフォルトで、2.4.10 より前のカーネルで機能する非浮動スタック・モードになります。注: この変数を設定しても、プログラムは 2.2 カーネルで実行していると想定しません。単に、浮動スタック機能を使用不可にするだけです。
単一プロセッサー・マシンは、このカーネルの欠陥による影響を受けません。
Linux
SuSE SLES 8 上で install.sh スクリプトを使用する (Defect 161398)
SuSE SLES V8 Linux プラットフォームに WebSphere Application Server アドバンスド・シングル・サーバー版 バージョン 4.0.6 をインストールする場合は、その前に install.sh コマンド・スクリプトの次の行をコメント化してください。
#export LD_ASSUME_KERNEL=2.2.5
この行をコメント化すると、製品のインストール中に次のエラーが生成されずに、インストールが続行されます。
/home/Build/AEs/java/jre/bin/exe/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
この行をコメント化すると、フィックスパック・インストーラーの使用時に次のエラーも現れないようになります。
error while loading shared libraries: libpthread.so.2: cannot open shared object file: No such file or directory
Solaris オペレーティング環境
インストール・ウィンドウの最小化による障害 (Defect 121011)
WebSphere Application Server V4.0 をインストールするときにインストール・ウィンドウをいったん最小化してから再び最大化すると、インストール・オプションのパネルが、インストール・ウィンドウの後ろに隠れます。これは、Solaris オペレーティング環境および IBM Software Development Kit ウィンドウ・ツールで motif を使用した場合に発生する、既知の問題です。
インストール・ウィンドウが最小化されている場合は、サイズ変更するか、復元時に Alt + F3 をクリックして、再び「インストール・オプション (Install Option)」パネルを表示してください。
Solaris オペレーティング環境
Domino Web サーバーと Secure Sockets Layer (SSL) 用に構成されたプラグインを持つ Solaris オペレーティング環境 2.8 で、始動時に例外が戻される (106012.RN)
Secure Sockets Layer (SSL) 用に構成されたプラグインで Domino Web サーバーが実行されている Solaris オペレーティング環境 2.8 システムで、始動時にサーバーが例外を受け取ります。これは、Domino と C++
コードとの非互換が原因です。
Solaris オペレーティング環境
DataDirect SequeLink サーバーを Solaris オペレーティング環境にインストールする (109652)
Solaris オペレーティング環境システム用の DataDirect SequeLink Server 5.1 CD-ROM の install.sh スクリプトにはステートメント which NISCAT
が含まれており、これにより一部のシステムでスクリプトが失敗することがあります。
このスクリプトは、このモジュールがすべての Solaris オペレーティング環境システム上で使用可能になっていることを前提としています。 install.sh スクリプトを実行してこのコマンドで失敗した場合は、このコマンドを除去すると、DataDirect SequeLink Server が正常にインストールされるはずです。
フィックスパック 4.0.6 以降の場合、直前の フィックスパック 以降に適用したすべての暫定修正が、最新の フィックスパック のインストール前に自動的にアンインストールされます。この自動アンインストールによって、確実にテストされたファイルを使用するようにすることができます。暫定修正がアンインストールされていないにもかかわらず フィックスパック をインストールすると、暫定修正のファイルの一部が フィックスパック によって上書きされる可能性があるため、この機能が必要になります。これが上書きされると、コードは不安定になります。
直前の フィックスパック・インストール以降に適用した修正だけがアンインストールされます。
最新の フィックスパック をインストールする前に行われるイベントの例を以下に示します。
最新の フィックスパック は暫定修正 PQ00002 および PQ00003 をアンインストールします。これらの暫定修正は、フィックスパック 4.0.5 の後にインストールされたものであるためです。
直前の フィックスパック の後にインストールされた暫定修正だけが除去されます。
フィックスパック のアンインストールの場合も同じことが行われます。
Windows 2000
Windows NT
WebSphere Application Server を iPlanet 6.0.1 と一緒にインストールできない (Defect 132342.RN)
iPlanet 6.0.1 と一緒に WebSphere Application Server バージョン 4.0.1 を完全にインストールすることはできません。
この問題を回避するには、次のステップを使用してください。
Windows 2000
Windows NT
IBM HTTP Server がインストールされていない場合、WebSphere Application Server のインストール・プログラムが GSK ライブラリー・パスで Windows システム・パスを更新しない (114353.RN)
「カスタム・インストール」オプションを使用して Windows プラットフォームに WebSphere Application Server をインストールしているときに、 IBM HTTP Server をインストールしないことを選択した場合は、システム・パスに GSK ライブラリーへのパスを手動で追加しなければなりません。これは、Secure Sockets Layer (SSL) を使用するアプリケーション・サーバーとの通信に、IBM HTTP Server プラグイン以外の Web サーバー・プラグインを使用したい場合にのみ必要です。パスの追加後、プラグインを Web サーバーに正しくロードするために、システムをリブートしてください。 GSK が C: ドライブにインストールされる場合、 C:\Program Files\IBM\gsk5\lib をシステム・パスに追加します。
Windows 2000
Domino Web サーバーと一緒に /WSsamples を使用できない (Defect 131884)
Domino Web サーバーを使用して http://<host name>/WSsamples/index.html にアクセスしようとすると、次のエラー・メッセージを受け取ります。
Exception and or log files and location relevant to defect: 404 error in browser
この問題に対処するには、下記のステップを完了してください。
URL リダイレクトの構成方法の詳細については、Domino ヘルプ・ファイルを参照してください。
Windows 2000
Windows NT
iPlanet Web サーバーを使用するには、特定の Windows ユーザー ID と権限が必要である (110672)
iPlanet Web サーバー、エンタープライズ版 4.0 をインストールおよびテストする前に、ご使用のマシンが WebSphere Application Server が使用しているのと同じ管理 ID を使用していること、および ID のユーザー権限に拡張ユーザー権限の「オペレーティング・システムの一部として動作」が含まれていることを確認してください。ユーザー ID およびユーザー権限を検査および設定するには、「 User Manager」を使用します。(Windows NT の場合、「スタート」>「プログラム」>「管理ツール (共通)」>「User Manager」を選択します。) Windows ヘルプでは、User Manager に関する情報を参照できます。
インストールおよび構成に戻る
起こり得る問題と推奨される修正方法に戻る
フィックスパック をインストールした後でアプリケーションを WebSphere Application Server アドバンスド・シングル・サーバー版にインストールし、その後で フィックスパック をアンインストールした場合は、server-cfg.xml ファイルが フィックスパック のインストール前の構成に復元されるため、アプリケーションを使用することができます。フィックスパック のインストール後に追加されたアプリケーションを保存するには、以下のようにします。
WebSphere Application Server バージョン 4 の フィックスパック 5 をアンインストールし、なおかつ Java2 セキュリティーを使用可能にしている場合は、アプリケーション・サーバーを始動する前に、 Java 仮想マシン (JVM) Java2 プロパティーをサーバー設定から除去するか、あるいは JVM Java2 プロパティーの「Enable Java2 Security」設定を false に変更する必要があります。 Java2 プロパティーを除去せず、また Java2 セキュリティー・プロパティーも false に設定しないと、アプリケーション・サーバーは始動しません。既に フィックスパック をインストール済みで、その最新バージョンだけを除去する場合は、これらの変更を行う必要はなく Java2 セキュリティー対応サーバーは正常に始動します。
非 root ユーザーとして Linux プラットフォーム上の WebSphere Application Server をアンインストールしようとすると、次のエラー・メッセージが表示されます。
/opt/WebSphere/AppServer/properties/sas.server.props を計算しようとしたエラーです (Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.server.props) /opt/WebSphere/AppServer/properties/sas.client.props を計算しようとしたエラーです (Error trying to calculate for /opt/WebSphere/AppServer/properties/sas.client.props)
これらのエラーを回避するには、root
ユーザー ID でログインして製品のアンインストールを再度試みてください。
WebSphere Application Server をアンインストールした後で、iPlanet Web サーバーまたは Apache HTTP Server を再始動できない場合は、アンインストール・プログラムが obj.conf ファイルからプラグイン情報を除去していない可能性があります。
iPlanet でこの問題を回避するためには、obj.conf ファイルから次の行を除去してください。
Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="full/path/to/module" Init fn="as_init" bootstrap.properties="full/path/to/plugin/config/file" Service fn="as_handler"
Apache でこの問題を回避するためには、 httpd.conf または srm.conf ファイルから次の行を除去してください。
LoadModule app_server_http_module full/path/to/module Optional AddModule mod_app_server_http.c WebSpherePluginConfig full/path/to/config
その後、サーバーを再始動します。
アンインストールに戻る
起こり得る問題と推奨される修正方法に戻る
AIX
Linux
Solaris オペレーティング環境
現行のシステム構成に重複するエイリアスを持つ VirtualHost 項目が含まれているときに、 (WASPostUpgrade を手動で実行して) WebSphere Application Server アドバンスド版にマイグレーションしようとすると、XMLConfig によりエラーがログに記録されます。
この条件が原因で WASPostMigration はエラーを報告し、トランスポート・プラグイン情報は生成されません。しかし、すべてのマイグレーション構成は正常にインポートされます。重複したエイリアス情報が実際に問題であるかどうかを調べ、問題がある場合は訂正します。手動で GenPluginCfg を実行して、トランスポート情報を更新してください。
マイグレーションがインストール・プロセスの一部として実行された場合、および重複したエイリアスが問題を起こさない場合は、このエラーは管理サーバーのログにも記録されます。
WebSphere Application Server バージョン 3.0.x から WebSphere Application Server バージョン 4..0.x にマイグレーションする場合、ノードの従属クラス・パス項目が適用可能で、なおかつまだアプリケーション・サーバーのクラス・パスの項目として組み込まれていない場合は、各アプリケーション・サーバーのクラス・パスにその従属クラス・パス項目を追加してください。
2 つの異なる WebSphere Application Server ドメイン間で java.math.BigDecimal クラスを渡すときに、ドメインのいずれかを、IBM Software Development Kit 131 を備えた WebSphere Application Server バージョン 4.0.4 にマイグレーションする場合、問題が起きる可能性があります。その理由は、java.math.BigDecimal クラスが、IBM Software Development Kit で変更されたからです。
旧バージョンの WebSphere Application Server 上の IBM Software Development Kit 131 とオブジェクト・リクエスト・ブローカー (ORB) は、その違いを処理できない場合があります。 WebSphere Application Server バージョン 4.0.4 と WebSphere Application Server バージョン 3.5.6 間でこのクラスを渡す場合は、問題ありません。
WebSphere Application Server バージョン 3.5.5、 WebSphere Application Server バージョン 4.0.1、および WebSphere Application Server バージョン 4.0.2 の ORB には、 IBM Software Development Kit 131 と IBM Software Development Kit 130 または IBM Software Development Kit 122 における java.math.BigDecimal クラスの違いを ORB が処理するための fix があります。 WebSphere Application Server バージョン 3.5.5 の fix は PQ60335 です。 WebSphere Application Server バージョン 4.0.1 の fix は PQ60336 です。 WebSphere Application Server バージョン 4.0.2 の fix は PQ60336 です。
ユーザー独自のコードが WebSphere Application Server バージョン 4.0.4 と、旧レベルの WebSphere Application Server との間でクラスを渡し、そのクラスが 2 つの WebSphere Application Server ドメインで異なるバージョンを持っている場合は、 WebSphere Application Server バージョン 3.5.5、バージョン 4.0.1、またはバージョン 4.0.2 の fix も必要になります。
注: これは、Solaris オペレーティング環境を除き、すべてのオペレーティング・システム上の IBM Software Development Kit に適用されます。
WebSphere Application Server バージョン 3.5.x スタンダード版から WebSphere Application Server バージョン 4.0.x にマイグレーションする場合、次のエラー・メッセージが WASUpgrade.log で見つかることがあります。
MIGR0206E: ディレクトリーをコピーできません。(Unable to copy directory.) ソース /usr/WebSphere/AppServer/ deloyedleEJBs が存在しません。(The source /usr/WebSphere/AppServer/ deloyedleEJBs does not exist.)
MIGR0206E: ディレクトリーをコピーできません。(Unable to copy directory.) ソース /usr/WebSphere/AppServer/ deployedEJBs が存在しません。(The source /usr/WebSphere/AppServer/ deployedEJBs does not exist.)
これらのエラー・メッセージにより、WASPreUpgrade.log ファイルはそのマイグレーションが失敗したことを示します。マイグレーション障害メッセージとこれらのエラー・メッセージは無視できます。
WebSphere Application Server バージョン 3.x からバージョン 4.0.x にマイグレーションする場合、 Web アプリケーション・バージョン 3.x の文書ルートとクラスパス属性は、 WAR ファイルにコピーされるファイルを指すポインターとして使用されます。マイグレーションでは、これらのパスは、完全修飾パスかシンボリック・リンクのどちらかであると想定されます。したがって、このパスがアプリケーション・サーバー上の作業ディレクトリーに相対する場合、ファイルは WAR ファイルにコピーされません。
マイグレーションが実行されていない場合は、管理コンソールを使用して、完全修飾パスまたはシンボリック・リンクを反映するように、文書ルートとクラスパス属性を変更してください。
マイグレーションを実行しても、サーブレット・クラス、JavaServer Pages (JSP)、および Web リソースが WebSphere Application Server バージョン 4.0 環境に移動されない場合は、次のいずれかの方法を実行してください。
WebSphere Application Server バージョン 3.x から 4.0.x にマイグレーションするときに、マイグレーション・ツールは Web アプリケーションのサーブレット・コードへのポインターとして、3.x の Web アプリケーションのクラス・パス属性を使用します。このツールは通常、各パス項目の下で見つかったすべてのファイルを WAR ファイルの class または lib サブディレクトリーにコピーします。このコピーには、複数の Web アプリケーションが使用する、中央に置かれたすべてファイルが含まれます (そのファイルが Web アプリケーションのクラス・パス項目として組み込まれている場合に限る)。
たとえば、Web アプリケーションが次のクラス・パス項目を持っている場合、ツールは servlets、utilities、および lib ディレクトリーに下で見つかったすべてのファイルを WAR ファイルにコピーします。
<web-application name="webApp1" action="update"> <classpath> <path value="e:\WebSphere\AppServer\hosts\default_host\webApp1\servlets"/> <path value="e:\utilities"/> <path value="e:\libraries\version2\lib"/> </classpath> <web-application name="webApp2" action="update"> <classpath> <path value="e:\WebSphere\AppServer\hosts\default_host\webApp2\servlets"/> <path value="e:\utilities"/> </classpath>
WebSphere Application Server バージョン 4.0 の フィックスパック 2 以降では、-webModuleAdditionalClasspath と呼ばれる新しいコマンド行パラメーターが WASPostUpgrade ファイルに追加されます。このパラメーターにより、WAR ファイルにコピーしたくない特定のファイルのパスとファイル名を指定することができます。代わりに、-webModuleAdditionalClasspath パラメーターによって指定された 1 つ以上のファイルが、各 Web アプリケーションのクラス・パス項目を基に、 Web モジュール (ibm-web-ext.xmi) additionalClassPath 属性の拡張子に追加されます。さらに、WAR ファイルにコピーしたくないファイルが含まれたディレクトリーを指定することができます。代わりに、指定されたディレクトリーまたはそのサブディレクトリーで見つかったディレクトリーまたは JAR ファイルが、各 Web アプリケーションのクラス・パス項目を基に、Web モジュールの additionalClassPath 属性に追加されます。
引き続き上記の例を使用します。e:\utilities ディレクトリーに commonUtilities.jar ファイルがあり、 WAR ファイルに保管してはいけないファイルが e:\libraries\version2\lib ディレクトリーにあると想定します。Windows プラットフォーム上では、以下のコマンドを発行して WASPostUpgrade ファイルを呼び出すことができます。 (UNIX プラットフォームの場合も、同様の操作を実行してください。) このコマンドにおいて、c:\backup_directory はマイグレーション・バックアップ・ディレクトリーで、wsnodename は adminNodeName です。以下に示す例では、1 行のコマンドが、見やすくするために 2 行に分けて示されていることに注意してください。
WASPostUpgrade c:\backup_directory -adminNodeName wsnodename -webModuleAdditionalClasspath e:\utilities\commonUtilities.jar;e:\libraries\version2\libcommonUtilities JAR ファイルと e:\libraries\version2\lib パスの lib ディレクトリー (およびそのサブディレクトリー) にあるすべてのファイルは WAR ファイルにコピーされません。また、 WebSphere Application Server バージョン 4.0.x にマイグレーションされた webapp1 の Web モジュールの ibm-web-ext.xmi ファイルに次の項目が現れます。
additionalClassPath="e:\utilities\commonUtilities.jar;e:\libraries\version2\lib" また、バージョン 4.0.x にマイグレーション済みの webapp2 用の Web モジュールの ibm-web-ext.xmi ファイルには、次の項目が記録されます。
additionalClassPath="E:\utilities\commonUtilities.jar;"
WebSphere Application Server バージョン 4.0 の フィックスパック 2 では、サーバー・グループの属性のリストに clone-only 属性が追加されました。
どの属性が clone-only かを調べるには、インフォセンターの項目『6.6.22.0: サーバー・グループのプロパティー』を参照してください。
これは、XMLConfig を使用してどのサーバー・グループ属性を更新できるかに影響します。 clone-only として識別される属性が指定された場合、その属性は無視されます。
その結果、モデルのクローンを WebSphere Application Server バージョン 4.0.4 またはそれ以降にマイグレーションする場合、一部のサーバー・グループ属性が各クローンに伝搬されません。
マイグレーション後、各クローンを手作業で更新し、これらのタイプのサーバー・グループのプロパティーを設定してください。各クローンでは、その標準出力が stdout.txt に設定されており、標準エラーが stdout.err に設定されています。
WebSphere Application Server アドバンスド・シングル・サーバー版からアドバンスド版へマイグレーションする場合は、マイグレーション・プロセスを始める前に下記のディレクトリーのコピーを保管してください。
\config \installableApps \installedApps \properties
インストール・プロセスによってマイグレーションが正常に実行された後、前述のディレクトリーをアドバンスド版のインストール・ディレクトリーに復元します。
sas.server.props ファイルには、管理サーバーの重要な情報が含まれています。マイグレーションの前に、sas.server.props ファイルをバックアップしてください。
マイグレーション前のプロセスが完了すると、WAS_MIGRATION_TEMP.properties という名前のフ ァイルが /tmp ディレクトリーに保管され、さらにマイグレーション前のプロセス中に指定されたマイグレーション・バックアップ・ディレクトリーにも保管されます。このマシン上のオペレーティング・システムのレベルをアップグレードする場合は、このファイルをマイグレーション・バックアップ・ディレクトリーから /tmp ディレクトリーへコピーする必要があります。 /tmp ディレクトリーは、オペレーティング・システムのレベルのアップグレード中に空になります。
WebSphere Application Server アドバンスド版のマイグレーション・プロセスは、 WebSphere Application Server バージョン 4.0.x bin ディレクトリーにある admin.config ファイルを更新します。 この更新の副次作用の 1 つは、ブランク文字およびコメントがこの処理中にファイルから除去されることです。
WebSphere Application Server がインストールされた後、bin サブディレクトリーには、admin.config.bak と呼ばれる admin.config ファイルのコピーがあります。しかし、このファイルは、管理サーバーの始動時に消去されます。管理サーバーが始動される前に、admin.config.bak ファイルを別の名前でコピーすることをお勧めします。このファイルを、インストールされている admin.config ファイルの元の値の記録として使用します。
WebSphere Application Server バージョン 3.0.2.x からバージョン 4.0.x にマイグレーションするときに、WASPreUpgrade プログラムが実行されます。このプログラムは java.io.FileNotFoundException メッセージを戻します。見つからないファイルは、 content-type.properties です。この例外メッセージは無視してください。
インストール・プログラムの実行中に WebSphere Application Server をバージョン 3.x からバージョン 4.0.x にマイグレーションしており、なおかつ既存のパージョン 3.x 環境の保管中に重大なエラーが発生した場合は、次のステップを実行してバージョン 3.x 構成をマイグレーションしてください。注: このステップは Windows ベースのシステム用です。UNIX ベースのシステムの場合は、
.sh
をコマンド行に追加してください。
waspreupgrade c:\backup_directory c:\current_3.x.x_WebSphere_directory node name
ここで、node name は adminNodeName です。場合により、 waspreupgrade コマンドは必ずしも成功しない点に注意してください。有効な構成が保管されていることを確認するために、ファイル c:\backup_directory\websphere_3x_backup.xml が存在することを確認してください。このファイルが存在しない場合は、 c:\current_3.x.x_WebSphere_directory ディレクトリーから次のコマンドを入力してください。
xmlconfig -export c:\backup_directory\websphere_3x_backup.xml -adminNodeName nodename
WASPostUpgrade c:\backup-directory -adminNodeName nodename
WebSphere Application Server バージョン 3.x からバージョン 4.0.x に構成をマイグレーションした後、 Java Database Connectivity (JDBC) ドライバー構成に関連する問題が発生することがあります。この問題が発生した場合、次のようなエラー・メッセージが表示されます。
javax.naming.NamingException: ClassNotFoundException: COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource
この問題は、使用中のデータ・ストアに前提条件のアップグレードが必要で、このアップグレードがオリジナルのデータ・ストアのバージョンとは異なるディレクトリー・ロケーションに保管されている場合に発生することがあります。この問題は、WebSphere Application Server バージョン 3.x の構成に定義されている JDBC 構成が、オリジナルのデータ・ストアのバージョンからのドライバーと、その関連ディレクトリー名を使用するために発生します。この構成がエクスポートされて WebSphere Application Server バージョン 4.0.1 にインポートされると、新しいデータ・ストアのバージョンではなく、オリジナルのディレクトリー名が使用されます。
WebSphere Application Server アドバンスド版でこの問題を訂正するには、「 リソース」ツリーの下の管理コンソールにある新しいデータ・ストアのディレクトリー名を使用するように、 JDBC ドライバーの「サーバー・クラスパス」項目を変更します。
WebSphere Application Server アドバンスド・シングル・サーバー版でこの問題を訂正するには、 configuration ディレクトリーにあるサーバー構成ファイルを変更します。デフォルト・ファイルは server-cfg.xml ですが、別のファイルを使用するように変更することができます。「リソース・プロバイダー 」スタンザに対する変更が必要で、正しいクラス・パス名を使用するように変更します。たとえば、DB2 を使用している場合は、下記のように変更します。
<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/ db2inst1//sqllib/java/db2java.zip" resourceProvider="JDBCDriver_3"/>
これを次のように変更します。
<installedResourceProviders xmi:id="ResourceProviderRef_3" classpath="/home/ db2inst1//sqllib/java12/db2java.zip" resourceProvider="JDBCDriver_3"/>
この問題は、同じディレクトリー構造をマイグレーションして使用した場合にも発生することがあります。 Windows NT の場合、db2java.zip ファイルの古いコピーが lib ディレクトリーに残ります。このコピーが、JDBC ドライバー・サーバーのクラス・パスによって指し示されるファイルの代わりにロードされます。この問題を解決するには、WebSphere Application Server の lib ディレクトリーから db2java.zip ファイルを除去してください。
マルチノードのモデル・クローン・ドメインを WebSphere Application Server 4.0.x にマイグレーションするときに、マイグレーションされた最初のノード以外のノードに、同じ EAR ファイルがマイグレーションされてインストールされると、下記のエラーが XMLConfig Import の出力に表示されます。
XMC0100E: アクションの更新はこの型のオブジェクトにはサポートされていません。 アプリケーションを再インストールするには、エンタープライズ・アプリケーション・エレメントで、「 delete」アクションを実行し、続けて「create」アクションを実行します。 (Update action is not supported on this type of object. To reinstall the application, use "delete" action followed by "create" action, on enterprise-application element.)
このエラー・メッセージは、無視してください。
さらに、マイグレーションされた最初のノードにインストールされた EAR ファイルに含まれている Web および EJB の各モジュール名は、リポジトリーに組み込まれます。マイグレーションによって後続のノード上にインストールされた同一の EAR ファイルに含まれている Web および EJB モジュールの名前が一致しない場合、これらのモジュールを含む最初のノード上にインストールされた EAR ファイルは、名前が一致しないノード上には手動でインストールおよび展開する必要があります。次のステップを完了してください (Windows NT または Windows 2000 では、UNIX プラットフォームと同等のステップを実行してください)。
EARExpander -ear e:\WebSphere\AppServer\installableApps\Big3App.ear -expandDir e:\WebSphere\AppServer\installedApps\Big3App.ear -operation expand -expansionFlags war
ここで、e:\WebSphere\AppServer\installableApps\Big3App.ear は展開したい EAR ファイルであり、 e:\WebSphere\AppServer\installedApps\Big3App.ear はその EAR ファイルを展開するディレクトリーです。
マルチノードのモデル・クローン・ドメインを WebSphere Application Server バージョン 4.0.x へマイグレーションする場合は、最後のノードがそのドメインに挿入された後に、各ノードごとに Web サーバーのプラグインを手動で更新しなければなりません。 WebSphere Application Server プラグインの構成の更新を手動で起動するには、各ノードごとに以下のことを実行してください。
WebSphere Application Server バージョン 4 (フィックスパック 4 適用済み) と共にインストールされたトラステッド・プロパティー・ファイル servers.properties および webseal.properties を調べてください。フィックスパック 3 では、WebSEAL 3.6 に対するすべての参照が WebSEAL に変更されています。これらのプロパティー・ファイルをカスタマイズしている場合は、フィックスパック でインストールされるファイルにそのカスタマイズを追加してください。 webseal36.properties を継続して使用しないでください。webseal と呼ばれる、 WebSEAL バージョン 3.6 と 3.7 に共通のインターセプターを使用してください。
独自のインターセプターを作成する場合は、クラス・ファイルが install_root\classes ディレクトリーにあり、そのインターセプターと関連したプロパティー・ファイルが install_root\properties ディレクトリーにあることを確認してください。また、インターセプター・クラスがパブリックで、引き数を取らないコンストラクターを使用するようにしてください。
初期化をサポートするインターセプターは、WebSphereBaseTrustAssociationInterceptor を拡張する必要があることに注意してください。またこれらのインターセプターは、引き続き TrustedAssociationInterceptor を実装しなければなりません。以下に例を示します。
public class WebSealTrustAssociationInterceptor extends WebSphereBaseTrustAssociationInterceptor implements TrustAssociationInterceptor
最後に、WebSeal と IBM HTTP Server 間の相互の Secure Sockets Layer (SSL) が WebSEAL バージョン 3.7 でサポートされています。SSL が正しくセットアップされていることを確認してください。WebSphere Application Server は、相互 SSL セットアップの妥当性検査を行いません。
WebSphere Application Server バージョン 3.x からバージョン 4.0.x へのマイグレーション時に、マイグレーション・ツールは、Web アプリケーションの .html、.gif、およびその他のファイルのポインターとして、バージョン 3.x の Web アプリケーションの document-root 属性を使用します。このツールは、通常、document-root で検出される最高 300 個のファイルを、WAR ファイルにコピーします。 document-root の下に 301 以上のファイルがあった場合、WASPostUpgrade ログ・ファイルに次の警告メッセージが表示されます。
MIGR0250W: Document Root ファイルの限界 300 を超えました。(MIGR0250W: Document Root file limit of 300 exceeded.) Web アプリケーション TestWebApp の一部のファイルしか、War ファイル TestWebApp.war にコピーされませんでした。(Not all files for Web Application TestWebApp copied to War File TestWebApp.war.)
フィックスパック 3 以降を適用した WebSphere Application Server バージョン 4 では、 WASPostUpgrade ファイルに -documentRootLimit という名前の新しいコマンド行パラメーターが用意されています。このパラメーターを使用して、マイグレーション・ツールが document-root から WAR ファイルにコピーするファイルの数を指定します。指定される値は、-1 より大きい有効な整数です。 documentRootLimit ファイルは、websphere_3x_backup.xml ファイルに含まれているすべての Web アプリケーションに適用されます。値が指定されていない場合、デフォルトは 300 ファイルです。
マップされたけれども、WebSphere Application Server 3.x エンタープライズ・アプリケーションに含まれていない Web リソースと Enterprise Bean は、マイグレーション中に、DefaultApplication と呼ばれる、1 つのデフォルトの Java 2 Enterprise Edition (J2EE) アプリケーションにマップされました。
フィックスパック 4 以降では、アプリケーション・サーバーごとに別々のデフォルト J2EE アプリケーションが作成されます。この場合、Web リソースと Enterprise Bean はインストールはされますがエンタープライズ・アプリケーションには含まれません。モデルに含まれているアプリケーション・サーバーに、Web リソースと Enterprise Bean がインストールされる場合、モデルごとに別々のデフォルト J2EE アプリケーションが作成され、モデルに含まれているアプリケーション・サーバー上にインストールされるすべての Web リソースと Enterprise Bean は、そのデフォルト・アプリケーションにマップされます。
このデフォルト・アプリケーションの名前は、application server name"_MigratedApp または "model name"_MigratedApp です。
WebSphere Application Server 4.0.x は、AIX 4.3.2 プラットフォームでは稼働しません。WebSphere Application Server バージョン 4.0.x にマイグレーションする前に、AIX バージョン 4.3.3 にアップグレードしてください。
Linux プラットフォーム上で WebSphere Application Server バージョン 3.02 からマイグレーションするときに、 JAVA_HOME が bin ディレクトリーの WebSphere 3.02 setupCmdLine.sh ファイルに定義されておらず、 bin ディレクトリーの WebSphere Application Server 3.02 XMLConfig.sh ファイルで JAVA_HOME 値を正しく派生できない場合、マイグレーション前のプロセス中にエラーが発生することがあります。マイグレーションを完了するには、 JAVA_HOME 設定を有効な値に設定してください。 WebSphere Application Server バージョン 3.02 setupCmdLine.sh ファイルの JAVA_HOME 設定を、有効な IBM Software Development Kit 1.1.x ディレクトリーを指すように変更して問題を訂正してから、再度マイグレーション・プロセスを実行してください。
WebSphere Application Server バージョン 3.x と WebSphere Application Server バージョン 4.0.x の間で、システム管理データベースのフォーマットが大きく変更されました。バージョン 4.0.x に使用されているデータベース名がバージョン 3.x に使用されていた名前と同じ場合は、そのデータベースを除去して、前提条件ソフトウェアの更新と同時に、マイグレーション処理中に作成し直す必要があります。デフォルトのデータベース名 was40 を使用することをお勧めします。
Solaris 2.6 オペレーティング環境の WebSphere Application Server の旧バージョンからマイグレーションする場合は、マイグレーション前のプロセスを実行するために、 IBM Software Development Kit 1.3 製品に必要なすべてのパッチをインストールする必要があります。これらのパッチは、IBM Software Development Kit 1.3 製品に同梱されている README.sparc ファイルにリストされています。
英語以外の Solaris オペレーティング環境の WebSphere Application Server の旧バージョンからマイグレーションを行うときに、デフォルトの /opt 以外のロケーションにインストールされた、英語版以外の Solaris のネイティブ・パッケージをマイグレーションしようとすると、インストール・プログラムは前のインストールの正しいインストール・ロケーションを検出します。
WASPostUpgrade スクリプトを実行して WebSphere Application Server バージョン 4.0.6 にマイグレーションする場合、WASPostUpgrade ログにはエラー・メッセージ MIGR0250W が含まれますが、このエラー・メッセージで、 WAR ファイルにコピーされるファイルの限界が誤って表示されます。以下に例を示します。
MIGR0250W: 文書ルート・ファイルの制限数 300 を超えています。 Web アプリケーション TestWebApp に関するすべてのファイルが WAR ファイル TestWebApp.war にコピーされたわけではありません。
デフォルトでは、WAR ファイルには最高で 300 個のファイルをコピーすることができます。ファイル数が 300 を超えると、MIGR0250W メッセージがログに記録されます。しかし -documentRootLimit パラメーターを 1000 に設定すると、最高で 1000 個のファイルを WAR ファイルにコピーできます。 WAR ファイルにコピーするファイルの数が 1000 を超えると、 MIGR0250W メッセージがログに記録されますが、その場合も、ファイル数が 300 の限界を超えていると指摘されます。このようにエラー・メッセージに誤りがあるのは、 -documentRootLimit パラメーターで構成する値により、実際にコピーできるファイル数が 300 から 1000 の範囲内になるためです。
300 という数はハードコーディングされた値です。コピーできるファイルの数は、 -documentRootLimit パラメーターで設定されますが、このパラメーターが構成されていない場合は 300 に設定されます。
現在、この問題に対する解決策はありません。
マイグレーションに戻る
起こり得る問題と推奨される修正方法に戻る
WebSphere Application Server アドバンスド・シングル・サーバー版のアプリケーション・サーバー・プロセスが始動せず、管理コンソールにアクセスできません。そのため、管理コンソールを使用して、サーバーの始動を妨げている可能性がある構成上の何らかの問題を訂正することができません。
この状態を正常に戻すには、以下のようにします。
http://localhost:9091/admin
あるいは、問題のサーバー構成ファイルを手動で編集してみることもできます。手動で変更を行う前に、必ずバックアップを取ってください。
特定のポートが使用中の場合、WebSphere Application Server が始動に失敗します。ブートストラップ・ポートが使用中の場合、WebSphere Application Server を始動するときに次のエラーが表示されることがあります。このエラーは、WebSphere Application Server の始動時に表示される「ポート 9000 の使用中エラー (Port 9000 in use error)」と同じです。
009.765.6005c5b F ネーム・サーバーがブートストラップ・サーバーの始動に失敗しました (009.765.6005c5b F Nameserver Failed to start the Bootstrap server) org.omg.CORBA.INTERNAL: マイナー・コード: 8 完了: いいえ (org.omg.CORBA.INTERNAL: minor code: 8 completed: No)
アドバンスド版でこの問題を訂正するには、次のプロパティー名を使用して、 admin.config ファイルのブートストラップ・ポート (デフォルトは 900) を変更してください。
com.ibm.ejs.sm.adminServer.bootstrapPort="901"
このプロパティーが admin.config ファイルに存在しない場合は、追加してください。詳しくは、WebSphere Application Server バージョン 4.0 インフォセンターの『6.6.46.0: 管理サーバー構成ファイルのプロパティー』を参照してください。
アドバンスド・シングル・サーバー版でこの問題を訂正するには、サーバー構成ファイル (デフォルトは install_root/config/server-cfg.xml) を編集して、 orbSettings の bootstrapPort 値を変更してください。たとえば、
<orbSettings xmi:ed="ORBConfig_1" enable="true" bootstrapHost="localhost" bootstrapPort="900">
を、次のように変更します。
<orbSettings xmi:ed="ORBConfig_1" enable="true" bootstrapHost="localhost" bootstrapPort="901">
Java Database Connectivity (JDBC) 問題のために管理サーバーを始動できない場合、 DB2 環境が正しくセットアップされていなかったということが理由として考えられます。 DB2 環境をセットアップするには、以下のようにします。
DB2_HOME/sqllib/java12/usejdbc2
を実行する。DB2_HOME/sqllib/db2profile
を実行する。管理リポジトリー・データベースの作成後、次のプロパティーを false に設定する前に、管理サーバーを完全に初期化させてください。
このプロパティーは、WebSphere/AppServer/properties ディレクトリーの logging.properties ファイルにあります。このプロパティーを使用して、イベント・ログのさまざまな性質を制御します。データベース作成後、管理サーバーを初めて始動する前に、この両方のプロパティーが false に設定されると、管理サーバーが NumberFormatExceptions を戻して初期化に失敗することがあります。
WebSphere Application Server アドバンスド版がローカル DB2 サーバーとともに AIX システムにインストールされており、 (インフォセンターに記載されているように) 次のコマンドが以前に実行されて DB2 が構成されている場合、管理サーバーは正常に始動されるはずです。
次のコマンドを入力して、EXTSHM 環境変数を設定します。 $ EXTSHM=ON $ export EXTSHM $ db2set DB2ENVLIST=EXTSHM
後で、管理サーバーが停止されるか、あるいはシステムがシャットダウンされると、DB2 も同様に停止します。ただし、次にシステムのバックアップを取って DB2 を始動すると、管理サーバーは、始動しようとする際に次のエラーで失敗することがあります。
重要なイベントの永続ストレージを初期化できませんでした。 (Could not initialize persistent storage for serious events.) COM.ibm.db2.jdbc.DB2Exception 例外を受け取りました: [IBM][CLI Driver] SQL1224N (Got exception COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N) データベース・エージェントは、始動して要求をサービスできないか、 データベース・システムのシャットダウンまたは強制コマンドの結果として終了されました。 (A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command.) SQLSTATE=55032
この問題からリカバリーするには、上記のコマンドを入力して、EXTSHM 環境変数を設定し、サーバーを再始動します。
環境変数が誤って再び設定解除されないようにするには、上記 3 行のコマンドを db2profile ファイル (db2profile ファイルが .profile を使用して提供されていると想定します) に追加して、この変数が常に有効になるようにします。
ネーム・サービス・メッセージは、Nanny サービス・プロセスが開始された後で、なおかつ管理サーバーがネーム・サービスを開始する前に発行されます。これらのメッセージは無視してかまいませんが、始動時にエラー・メッセージを発行するまで待機する時間を指定するための新しい admin.config プロパティーが追加されます。ディレクティブは com.ibm.ejs.sm.adminServer.startupTime=<time in seconds> です。
アプリケーション・サーバー・コンポーネントの始動に戻る
起こり得る問題と推奨される修正方法に戻る
すべてのオペレーティング・システム
WebSphere Application Server バージョン 4 (フィックスパック 3 適用済み) では、サーバー・グループのプロパティー・シート上のすべてのクローンに伝搬される属性の右側に、アイコンが追加されました。
アイコンは、次のように表示されます。
「Java 仮想マシン (JVM) の設定」パネルのシステム・プロパティーを複製するために「 除去」プッシュボタンを使用できない点に注意してください。プロパティーを除去する唯一の方法は、該当する名前と値のペアを除去して、「 適用」をクリックするという方法です。
Windows プラットフォームの場合、ツールの「設定の変更 」ダイアログに、Netscape か Internet Explorer のいずれかを選択し、HTML ヘルプ・ファイルを表示するブラウザーの位置を設定できるかのようなオプションがありますが、ログ・アナライザーの HTML ヘルプにはオペレーティング・システムのデフォルトのインターネット・ブラウザーを使ってしかアクセスできません。
UNIX プラットフォームでは、ツールの「設定の変更」ダイアログで、ブラウザーの実行可能ファイルの位置を明示的に設定することにより、 Netscape Navigator など、好きなインターネット・ブラウザーを使用してログ・アナライザーの HTML ヘルプにアクセスすることができます。 HTML ヘルプ・ファイルを表示するブラウザーとして Netscape または Internet Explorer のいずれかを選択できるように思われるオプションは、使用できません。
UNIX プラットフォーム上でブラウザーを指定する方法は、次のとおりです。
ログ・アナライザーを初めて始動したときやログ・アナライザーの設定ファイルが削除された後、ログ・アナライザーのシェル・ウィンドウに次の通知メッセージが表示されます。
waslogbrsys の入力ストリームを開けません
このメッセージは、ログ・アナライザーの実行には影響ないので無視してかまいません。
EARExpander がユーティリティー JAR または .zip ファイルを縮小しなくなった (Defect PQ61441)
WebSphere Application Server バージョン 4.0.2 以降、 EARExpander はユーティリティー JAR または .zip ファイルを縮小しなくなりました。
この問題に対処するには、次のどちらかを実行してください。
EAR ファイルを縮小するには、EARExpander.(bat|sh) -ear <$PATH>\test.ear -expandDir <$PATH>\ ear\test.ear -operation collapse を実行してください。
UNIX プラットフォーム上でヘルプを要求した後、次のメッセージが表示された場合は、ロケールがデフォルトの C ロケールに設定されている可能性があります。
ADGU2030E: 次のコマンドでブラウザーは始動できませんでした (ADGU2030E: The browser could not start with the command:) netscape /opt/WebSphere/AppServer/web/InfoCenter/was/06060200.html. 戻りコード 255 を受け取りました。(Received return code 255.) コマンド行からブラウザーを実行できること、およびアクセス制御が使用不可になっていることを確認してください。(Verify that you can run the browser from a command line and that access control is disabled.)
このエラーを回避するために、次のいずれかを実行してください。
ご使用のマシンに有効なロケールのリストを表示するには、locale -a
を実行します。
ロケールを設定するには、export LANG=locale
を実行します。ここで、locale は有効なロケールです。たとえば、United States English を設定するには、export LANG=en_US.iso88591 を実行します。ユーザーのプロファイルに永続的にこのロケールを設定します。
この問題は、HP-UX と Solaris オペレーティング環境に共通の問題ですが、ロケールが正しく設定されていない場合、AIX でも発生する可能性があります。
戻りコード 1
と一緒に ADGU2030E メッセージを受け取った場合は、アクセス制御が使用不可になっていることを確認してください。アクセス制御を使用不可にするには、xhost +
を実行します。
WebSphere Application Server バージョン 4.0.5 を使用しているときに、前のバージョンにバックアップする場合は、データ・ソースのパスワードを再入力してください。
デフォルトの URL プロバイダーは、WebSphere Application Server 管理クライアントと、クラスター内の 1 つのノード上のクライアントの XML export にしか表示されません。 「新規インストール」>「the other node」>「未使用」の順にクリックすると、デフォルト URL プロバイダーはストリングの終わりにセミコロンを追加します。ただし、ストリングの終わりにあるこのセミコロンは見えません。
現在、この問題を回避する方法はありません。
管理コンソール (GUI) およびコマンド行ツールに戻る
起こり得る問題と推奨される修正方法に戻る
Solaris オペレーティング環境
次の変更は、アプリケーション・クラス・ローダーに使用できます。これらの変更は、ほとんどのアプリケーションに対して透過的です。
モジュールの可視性の設定が Module であるアプリケーション・サーバーが始動中または実行時に停止することがあります。アプリケーション・サーバーの再始動により、この問題を回避できることがあります。完全にこの問題を回避するためには、モジュール可視性の設定を、Application、Server、CompCompatibility または J2EE (Java 2 Enterprise Edition) を使用するように変更してください。
クラス・ローダーの訂正は次のとおりです。
-DdiagThreadPort= コマンド行引き数をアプリケーション・サーバーの Java 仮想マシンに追加して、静的 TCP IP ポートをアプリケーション・サーバーの Dr. Admin スレッドに割り当てるように選択することができます。
以下のエラー・メッセージを受け取った場合は、 wscp ツールが WAR アプリケーションをリモートに配置することができません。このアプリケーションを配置するには、アプリケーション WAR ファイルを (ローカル・クライアント・マシンの代わりに) ターゲットまたはリモート・アプリケーション・サーバー・マシンに移動して、そのマシンから wscp クライアントを起動してください。
"WSCP0086E EnterpriseApp のインストールで例外が発生しました" "WSCP0106E RemoteArchiveInfo を取得できません..."
WAR ファイルのインストール中に、「 リソース・プロバイダー」の下に定義されている Java Message Service (JMS) リソースを選択します。
WebSphere Application Server バージョン 4.0.4 の適用後、プラグイン構成ファイル (plugin-cfg.xml) が変更されます。この変更の結果、いくつかの URI 名が省略され、代わりにその URI グループに "/*" が置かれます。以下に例を示します。
UriGroup Name="xxxxxxxxxxx/xxxxxxx/xxxxx" <Uri Name= "*.jsp" /> <Uri Name= "*.jsv" /> <Uri Name= "*.jsw" />
UriGroup Name=xxxxxxxxxxxxx/xxxxxxxxx> <Uri Name= "/*" />
バージョン 4.0.4 より前のバージョンまでは、アプリケーション・アセンブリー・ツール (AAT) を介した FileServingEnabler は、Web サーバー・プラグインを介して静的リソースを要求するときに、何の効果も持っていませんでした。オリジナルのプラグイン再生成コードは、スラッシュ "/" のコンテキスト・ルートに対して FileServingEnabler フラグを無視し、 "/*" のサーブレット・マッピングを追加しません。
"/" のコンテキスト・ルートに対して FileServing を使用可能にしている場合でも、それが使用可能されたことを認識しない場合があります。
この変更の理由は、次の通りです。
しかし、これは "/" のコンテキスト・ルートに対してのみの場合です。その他のすべての Web アプリケーションは、FileServing が使用可能になっていると、ルール・コンテキスト・ルートを追加します。あるいは、FileServing が使用可能になっていない場合、Web アプリケーションはそれぞれの個々の URI マッピングをリストから外します。これにより、URI マッピング・ルールは、デフォルトの "/" のコンテキスト・ルートの特殊ケースを持つ代わりに、すべてのコンテキスト・ルートで一貫性を持つようになります。
FileServingEnabled のときに特定のコンテキスト・ルートに対して各 URI マッピングをリストしない理由は、検索パスを減らすためです。要求が /contextRoot/ で開始されることをプラグインがすでに知っている場合、それはその要求を処理するために WebSphere Application Server に送信されます。 FileServing が使用可能になっていない場合は、各サーブレット・マッピングをファイル plugin-cfg.xml に追加し、これらの一致だけが WebSphere Application Server によって処理されることを確認する必要があります。
FileServingEnabled で、"/" のコンテキスト・ルートの Web アプリケーションがある場合は、Web サーバーは最早サービスを要求せず、仮想ホスト・マッピングが一致する場合には、 WebSphere Application Server にすべての要求を処理させます。
これをテストするためには、以下のステップを実行してください。
contextRoot/*.jsp contextRoot/j_security_check
デプロイメント・プロセス用のスクリプトを実行して、アプリケーションが既に存在しているかどうかを調べます。アプリケーションが存在している場合は、アプリケーション・サーバーを停止して、除去します。これで、以下の管理例外は発生しなくなるはずです。
ExceptionUtil X CNTR0020E: メソッド findRepositoryObjectByName (Bean 上) の処理中に非アプリケーション例外が発生しました。 BeanId(admin#repository.jar#ClientAccess, null): java.rmi.RemoteException: ; nested exception is: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException: javax.ejb.ObjectNotFoundException
ObjectNotFoundException が予期されるのは、以下の wscp コマンドを発行してリポジトリー内のエンタープライズ・アプリケーションの属性を表示する際に、リポジトリー内にエンタープライズ・アプリケーションが見つからない場合です。
EnterpriseApp show /EnterpriseApp: dumpApp/ -asInteger
wscp ClientRepository は、ClientAccessBean.findRepositoryObjectByName() を呼び出して、リポジトリー内で見つからないエンタープライズ・アプリケーション・オブジェクトを取得します。エンタープライズ・アプリケーション・オブジェクトは、アプリケーション名で検索されます。 wscp は、次のエラー・メッセージをスローします。
WSCP0061E: オブジェクトが見つかりません : /EnterpriseApp:dumpApp/
管理サーバーも、メソッド findRepositoryObjectByName の処理中に、 ObjectNotFoundException 例外および Non-application 例外をスローします。
これらの例外がスローされないようにするには、既存のアプリケーションからコマンドを発行するようにします。
Solaris オペレーティング環境では、アプリケーション・サーバーは、 "java.lang.OutOfMemoryError" で負荷がかかると破壊されることがあります。これはアプリケーション・サーバーの stderr.log ファイルに記録されます。
このエラーを回避するためには、適切な最大永続ヒープ・サイズ値を Java 仮想マシン (JVM) に渡してください。デフォルトは低過ぎます。現行の推奨値は 64 MB です。
管理コンソールでこの変更を加えるには、次のステップを実行してください。
Solaris オペレーティング環境
Solaris オペレーティング環境で Java Database Connectivity (JDBC) ResultSets を処理する際のパフォーマンスの問題 (Defect 144271.RN)
Solaris オペレーティング環境にある WebSphere Application Server でアプリケーションを実行しており、なおかつそのアプリケーションが大きな ResultSets を処理している場合、スタンドアロン・アプリケーションで同じコードを実行しているときにパフォーマンスが遅くなることがあります。
この問題を回避するためには、Sun JDK 1.3 HotSpot -client オプションをアプリケーション・サーバーの Java 仮想マシン (JVM) 構成に追加してください。
-server オプション対 -client オプションの詳細情報については、 IBM WebSphere Application Server バージョン 4.0 アドバンスド版の インフォセンター にある項目『9.1: チューニング・ガイド > Sun JDK 1.3 HotSpot -server warmup』を参照してください。
この問題は、JVM のバグが原因です。
バグ ID 概要 日付 4490353 JDK 1.3.1 および 1.4.0-beta でクライアント VM よりサーバー VM が遅い 2002 年 3 月 6 日
このバグは、Sun JDK 1.3.1_04-b02 で修正されています。このバージョンを入手するには、サポート担当者に連絡してください。問題の回避策を使用した場合は、それを除去して、アプリケーション・サーバーのデフォルト設定に戻してください。
アプリケーション・サーバーに戻る
起こり得る問題と推奨される修正方法に戻る
J2EE (Java 2 Enterprise Edition) アーカイブの編集と検査に使用されるアプリケーション・アセンブリー・ツール (AAT) のフレームワークは、アーカイブ内での Java の反映のためにカスタム・クラス・ローダーを使用します。場合によっては、 AAT でのクラス・ローダーの動作がランタイムでの動作と整合していないことがあります。たとえば、クラスを反映できないときに妥当性検査エラーを受け取る可能性があります。あるいは、アーカイブの保管時に反映の問題やリンケージ・エラーが検出されることもあります。
これらのクラス・ロード・エラーは、次の 2 つのうちのいずれかの問題か原因です。
クラス・ロード・エラーを回避するには、この 2 つの問題を訂正してください。
アプリケーション・アセンブリー・ツールで、以下の操作を実行した場合の問題を説明します。
WAR ファイルはドラッグできません。この問題を回避するには、新規アプリケーション・ウィンドウのツリー・ノードからファイル (Ejb .jar/Web Module .war/Ejb client .jar) をインポートしてください。
AIX プラットフォームで assembly.sh
と入力して
WebSphere アドバンスド版のアプリケーション・アセンブリー・ツールを始動すると、
java.lang.OutOfMemoryError 例外が戻されることがあります。この問題を解決するには、assembly.sh ファイルの Java コマンド行に -mx192m オプションを追加してみてください。この結果、Java コマンド行は次のようになります。
$JAVA_HOME/jre/bin/java \ -Xmx192m \ -Dcom.ibm.itp.location=$WAS_HOME/bin \ -Dserver.root=$WAS_HOME \ -Dws.ext.dirs=$WAS_EXT_DIRS \ -classpath $WAS_CLASSPATH com.ibm.ws.bootstrap.WSLauncher \ com.ibm.ejs.assembly.gui.AssemblyTool
リモート・マシンから WebSphere Application Server のツール
(たとえば、アプリケーション・アセンブリー・ツール) にアクセスする場合、リモート・ブラウザーがヘルプ・ファイルをリモートに表示できない点に注意してください。このヘルプ・ファイルは、ローカルにインストールされたブラウザーからしか表示できません。リモート・マシン上のすべての Netscape セッションを閉じ、「
ヘルプ」をクリックして新しい Netscape セッションを開始してください。これにより、ヘルプ・テキストを表示することができます。
Web アプリケーション・アーカイブ間でリソース (JavaServer Pages および静的) を共用するための新機能が追加された (Defect PQ65763.RN)
リソース (JavaServer Pages (JSP) および静的) を Web アプリケーション・アーカイブ間で共用できるように、WebSphere Application Server は FileServingEnabler と JSP プロセッサー両方のためのサーブレット初期化パラメーターを作成しました。これにより、要求されたリソースが Web アプリケーション・アーカイブの共用文書ツリーに見つからない場合、デベロッパーがコンマで区切ったディレクトリー、JAR ファイル、またはその両方のリストを検索パスとして指定できるようにしました。
この新機能は、次のようにしてアプリケーション・アセンブリー・ツール (AAT) から使用可能にすることができます。
注: 値は、オプション 1 とオプション 2 の両方を混合できる、コンマで区切られたリストを受け入れます。
以下は、配置されるアプリケーションでこの機能がどのように使用可能になっているかを示す、サンプルの ibm-web-ext.xmi ファイルです。
parameter name = extendedDocumentRoot
parameter value = Web application archive relative or absolute path to resource
<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmi:id="WebAppExtension_2" reloadInterval="5" reloadingEnabled="true" defaultErrorPage="error.jsp" additionalClassPath="" fileServingEnabled="true" directoryBrowsingEnabled="true" serveServletsByClassnameEnabled="true"> <webApp href="WEB-INF/web.xml#WebApp_ID"/>> <jspAttributes xmi:id="JSPAttribute_1" name="keepgenerated" value="true"/> <jspAttributes xmi:id="JSPAttribute_2" name="largefile" value="false"/> <jspAttributes xmi:id="JSPAttribute_3" name="extendedDocumentRoot" value="testcase.jar,my-test.jar,my-test.war/WEB-INF/lib/war_level.jar"/> <fileServingAttributes xmi:id="FileServingAttribute_1" name="extendedDocumentRoot" value="testcase.jar,my-test.jar,my-test.war/WEB-INF/lib/war_level.jar"/> </webappext:WebAppExtension>
この新機能には、次のような制限があります。
アプリケーション・アセンブリー・ツール (AAT)
起こり得る問題と推奨される修正方法に戻る
使用している Entity Bean のタイプに該当する問題および修正方法を参照してください。
Enterprise Bean のクラスを更新するための動的な再ロードは、WebSphere Application Server バージョン 4.0.4 では使用できません。 Enterprise Bean の実装クラスを更新したい場合は、次のステップを実行してください。
WebSphere Application Server バージョン 4.0.2 では、パフォーマンス上の大きな改善が加えられました。この改善により、WebSphere 接続プール内の準備済みステートメント・キャッシュのセマンティクスが変更されました (Defect PQ53331 および 115405)。ただし、この改善により、「準備済みステートメント・キャッシュ・サイズ」(ステートメント・キャッシュ・サイズ) の意味が変わりました。
前のバージョンでは、データ・ソースまたはプールにキャッシュされる準備済みステートメントの合計最大数を示しました。これ以降の フィックスパック では、この値はやはり 1 つのデータ・ソース当たりの準備済みステートメントの数を示していますが、数が接続数で除算され、1 つの接続 当たりの準備済みステートメントの数が示されるようになりました。準備済みステートメントの数が接続数よりも少ない場合は、 1 接続当たり 1 つの最小数が割り振られます。たとえば、100 の準備済みステートメントと 50 の接続があるとすると、1 接続当たり 2 つが割り振られ、10 の準備済みステートメントと 50 の接続があるとすると、1 接続当たり 1 つが割り振られます。ステートメント・キャッシュのサイズは調整することができます。デフォルトのステートメント・キャッシュが 100 であるとすると、接続プール・サイズによっては、このサイズが妥当です。プール・サイズが大きい場合、ステートメント・キャッシュ・サイズを増やす必要がある場合があります。
WebSphere Application Server バージョン 4.0.x で、ステートメント・キャッシュ・サイズを「 データ・ソース」の「 接続プール」タブから設定します。これには、「ステートメント・キャッシュ・サイズ」という名前の独自のフィールドがあります。
Enterprise Bean の分離レベルが、Oracle でサポートされていない反復可能読み取り (RR) に設定されている場合、WebSphere Application Server は安全のため、分離レベルを直列化可能にアップグレードします。しかし、Oracle には、XA が「直列化可能」では実行できないという制約があります。 Oracle トレースに、次のエラー・メッセージが表示されます。
joxasStart(): Got a 'C' error:24776 jojniStart(): err = 24776
WebSphere Application Server は StaleConnectionException 例外をスローします。
このエラー・メッセージが表示されないようにするには、XA の使用時に、Bean メソッドで RR または Serializable 分離レベルを使用しないでください。
基本的な 1 次キーを使用する CMP ベースの Entity Bean を持つ EJBModule をコンパイルすると、以下のようなエラー・メッセージを受け取ることがあります。
ejbModule/com/ibm/ejb/cb/samples/big3/tier2 の内容をコンパイルしています (Compiling content of ejbModule/com/ibm/ejb/cb/samples/big3/tier2) (12 個の問題を検出) クラスパスのすべてのリソースをコピー中 ((12 problems found) Copying all resources on the class path) (12 個の問題を検出) 構築は完了しました ((12 problems found) Build done) Java の構築が完了しました (Java build completed) /Big3BRB.jar 上に検証プログラムを呼び出しています (Invoking Validation on /Big3BRB.jar.) ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSCMPClaimHomeBean.java(62): コンストラクター java.lang.Integer() が未定義です (The constructor java.lang.Integer() is undefined) ... ejbModule/com/ibm/ejb/cb/samples/big3/tier2/EJSJDBCPersisterCMPPolicyBean.java(197): コンストラクター java.lang.Integer() が未定義です (The constructor java.lang.Integer() is undefined) ワークベンチをシャットダウンします (Shutting down workbench.) 実行停止をします: コンパイル・エラーがレポートされました (Compilation Errors Reported Execution Halted: Compilation Errors Reported) エラー 12、警告 0、情報メッセージ 0 (12 Errors, 0 Warnings, 0 Informational Messages)
指定されたデプロイメント記述子では基本的なオブジェクト・キー (java.lang.Integer) を使用しましたが、デプロイメント記述子のマップ先のキー・フィールドを指定しなかったため、コンパイルが停止されました。これは複合キーとして残されました。したがって、配置ツールは、どのフィールドをキーとして使用するかが分からななったため、エラー・メッセージを戻しました。
上記の例で生成されたデプロイメント記述子の場合、<prim-key-class> エレメントは java.lang.Integer に設定されましたが、 1 次キーにマップすべき <cmp-field> エレメントを指定する <primkey-field> エレメントがありませんでした。
これを解決するには、アプリケーション・アセンブリー・ツールを使って使用するキー・フィールド (複合キー以外) を指定するか、 ejb-jar.xml を手動で編集して <primkey-field> エレメントを追加します。
CMP を持つ Entity Bean に対してファインダー・メソッドが呼び出され、なおかつファインダーが誤って定義された場合、 javax.ejb.FinderException が発生することがあります。この障害は、ファインダーが複数の EJB オブジェクト (java.util.Enumeration または java.util.Collection のいずれか) を戻し、なおかつファインダー・ロジックが、findMethodNameQueryString という名前のストリング定数にカプセル化された場合に発生します。この障害は、Java ストリング定数によってカプセル化された SQL SELECT ステートメントが誤っているために発生します。カプセル化された SQL 選択ステートメントが各 CMP フィールドに対する完全なリスト列名を組み込んでいないか、またはリスト列名が Entity Bean を正常に水和させるために必要な順序で表示されていないかのいずれかです。以下に掲げるのは、カプセル化された SQL 選択ステートメントが、必要な列名をすべて組み込んでいない場合に発生するエラーの例です。
ERROR: javax.ejb.FinderException: com.ibm.ejs.persistence.EnumeratorException original exception: com.ibm.ejs.container.ContainerInternalError:; nested exception is: COM.ibm.db2.jdbc.DB2Exception: [IBM][JDBCDriver] CLI0610E Invalid column number. SQLSTATE=S1002
注: findMethodNameQueryString という名前のストリング定数にロジックをカプセル化しないでください。以下では、上記の障害やこれに類似する障害が発生させずに、ファインダー・ロジックを EJB サーバーに正しく作成する方法を説明します。
EJB サーバー内でのファインダー・ロジックの作成
EJB サーバー環境の場合、CMP を持った Entity Bean のホーム・インターフェースに含まれる各ファインダー・メソッド (findByPrimaryKey メソッドを除き) に以下のファインダー・ロジックが必要です。
例として、AccountHome ホーム・インターフェースが以下のファインダー・メソッドを定義するとします。
Enumeration findLargeAccounts(float amount) throws RemoteException, FinderException;
また、AccountBeanFinderHelper インターフェースを以下のように作成する必要があります。
public interface AccountBeanFinderHelper { String findLargeAccountsWhereClause = "balance > ?"; }
アプリケーション・アセンブリー・ツールを使用してファインダー・ロジックも定義できます。各 CMP Entity Bean ごとに、アプリケーション・アセンブリー・ツールのツリー・ビューで Entity Bean と「メソッド拡張子 (Method Extensions)」選択項目を選び、各ファインダー・メソッドごとに「 ファインダー記述子 (Finder descriptor)」を設定します。「すべて選択 (Full select)」ラジオ・ボタンを使用することはお勧めできません。その理由は、このボタンを使用すると、必要な列名のリストと順序が使用されない場合、 javax.ejb.FinderException がスローされる結果となりやすいからです。「where 文節 (Where clause)」ラジオ・ボタンを使用して、列名および順序の正しいリストを入手してください。
Enterprise Bean に戻る
起こり得る問題と推奨される修正方法に戻る
すべてのオペレーティング・システム
UNIX
sas.server.props ファイルが破壊されていると、管理サーバーが始動に失敗することがあります。 sas.server.props ファイルには、管理サーバーの重要な情報が含まれています。定期的に sas.server.props ファイルをバックアップしてください。
Domino 5.09a Lightweight Directory Access Protocol (LDAP) セキュリティーをインストールする場合、LDAP レジストリー・プロパティーのデフォルト・フィルターを、 objectclass=dominoPerson ではなく、 objectclass=Person に設定してください。セキュリティー・センター・フォルダーの「認証 (Authentication)」セクションのプルダウン・メニューから、ディレクトリー・タイプ Domino 4.6 を選択してください。
セキュリティーが使用可能になったマルチサーバー・シナリオでは、なんらかの理由で 1 つ以上のサーバーが再始動する場合、既存のサーバーは、再始動されたサーバーに正常に再接続できません。
再始動されたサーバー上で起動されたリモート・メソッドは失敗し、既存のサーバーは停止状態のように見えます。
この動作の理由は、サーバーが再始動するときに、そのサーバー自体に新しいポートが再割り当てされますが、既存のサーバーはその新しいポートを検出できないからです。既存のサーバーは、再始動されたサーバーの最後の既知のポートに接続しようとします。それにより、接続がタイムアウトになります。
セキュリティーが使用可能になった複数のノード間で、ワークロード管理 (WLM) フェイルオーバーが正常に機能するには、管理サーバー、およびドメイン内の各ノードのすべてのアプリケーション・サーバーに、固定ポートを割り当てる必要があります。サーバーは毎回、同じハードコーディングされたポート上で始動されます。この問題を回避するには、次のステップを実行してください。
com.ibm.CORBA.ListenerPort=2000 com.ibm.CORBA.SSLPort=2001 com.ibm.CORBA.LSDPort=9000 com.ibm.CORBA.LSDSSLPort=9001
com.ibm.CORBA.ListenerPort=3000 com.ibm.CORBA.SSLPort=3001
注: セキュリティーが使用可能になっていない場合、この構成は必要ありません。
不定の時間が経過した後、Domino server 5.0.9a Secure Sockets Layer (SSL) 接続が失敗することがあります。この問題は、すべての UNIX プラットフォーム上で発生します。
ある時点で、Domino Server は有効な SSL 証明書が無効であると判断し、その後のすべての保護接続を許可しません。これは、Domino Web Server に負荷がかかっているときに発生し、スレッド・セーフでない時間変換ルーチンが原因です。失敗の最初の兆候が見られた時点で、次のようなメッセージが、Domino Server コンソール出力に表示されます。
07/18/2002 03:22:27 PM HTTP server: 証明書の開始日が現在の日付より後です (Certificate begin date is after current date) 07/18/2002 03:22:27 PM HTTP server: セキュリティー管理システム・エラー (Security administration system error) 07/18/2002 03:22:27 PM HTTP server: 9.42.73.160 に対して SSL セッションが始動しません (SSL session not started for 9.42.73.160)
この問題を解決するには、Domino Server のカスタマー・サポートに連絡し、SPR SUI5BALNA を参照してください。
RequestDispatcher.forward() を使用して無保護のサーブレットまたは JavaServer Page (JSP) から保護されたサーブレットまたは JSP に転送を実行しようとすると、許可障害 (HTTP 応答コード 403) が発生します。サーブレット仕様 2.3 のセクション 12.2 には、 RequestDispatcher の使用時にはセキュリティー・モデルは適用されないという記載があります。
この問題を解決するには、RequestDispatcher.forward( ) を呼び出す URI を保護する必要があります。こうすることにより、アプリケーションを WebSphere Application Server バージョン 5 にマイグレーションできるようになります。
これができない場合は、各アプリケーション・サーバーに以下のプロパティーを設定することで、無保護 URI から保護 URI に転送を行う際にユーザー確認が行われます。
com.ibm.ws.security.RequestDispatcherChallenge=true
このプロパティーをインプリメントするコードは、 1/06/2003 (2003 年 1 月 6 日) 以降の日付のあるセキュリティー累積フィックスに含まれています。
セキュリティーに戻る
起こり得る問題と推奨される修正方法に戻る
2 台の Sun Solaris マシンのクラスターで WebSphere Application Server を実行している場合、 Java 仮想マシン (JVM) システム・プロパティーをサーバー・グループからクローンに伝搬できません。 WebSphere Application Server バージョン 4 (フィックスパック 2 以降適用済み) の場合、システム・プロパティーは clone-only 属性に変更されています。システム・プロパティーはクローンに伝搬されませんが、クローン属性のプロパティーは追加または変更することができます。
ワークロードの管理に戻る
起こり得る問題と推奨される修正方法に戻る
すべてのオペレーティング・システム
Linux
Solaris オペレーティング環境
SuSE SLES 7.0 (Linux for Z/OS) に付属の Apache (1.3.19-40) と一緒に、WebSphere Application Server を実行する場合、この特定の Apache バージョンが、Extended Application Programming Interface (EAPI) コンパイルされていても、非 EAPI コンパイル WebSphere Application Server プラグインを使用してください。
Apache httpd.conf ファイルを構成する場合、次の行に変更を行います。
LoadModule app_server_http_module opt/WebSphere/AppServer/mod_app_server_http_eapi.so
変更後:
LoadModule app_server_http_module opt/WebSphere/AppServer/mod_app_server_http.so
非 EAPI モジュールで Apache を始動する場合、次の警告が表示されます。
[警告] ロードされた DSO /opt/WebSphere/AppServer/bin/mod_app_server_httpd.so が、プレーン Apache 1.3 API を使用しています ([warn] Loaded DSO /opt/WebSphere/AppServer/bin/mod_app_server_httpd.so uses plain Apache 1.3 API) このモジュールは、EAPI では破損する可能性があります (DEAPI で再コンパイルしてください) (this module might crash under EAPI! (please recompile it with DEAPI))
この状況では、警告を無視できます。
Linux
IBM HTTP Server で認証要求を作成できない (Defect 138035.RN)
Linux/390 マシン上で、コマンド行 IKEYMAN (IKEYCMD) を実行すると、次のエラー・メッセージが表示されることがあります。
java.util.MissingResourceException: バンドル用のリソースを検出できません (java.util.MissingResourceException: Can't find resource for bundle) java.util.PropertyResourceBunde. key GSKKM_<some option>.
たとえば、java -Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikmuser.properties com.ibm.gsk.ikeyman.ikeycmd <arguments> です。
IBM HTTP Server は、Secure Sockets Layer (SSL) 用に構成されていて、 WebSphere 管理サーバーが稼働中の場合、初期化中にハングすることがあります。
この問題を解決するには、以下の対処方法のいずれかを試してください。
SSLAcceleratorDisable
ディレクティブを挿入して、
IBM HTTP Server でのハードウェア暗号アクセラレーター・カードを使用不可にします。このディレクティブは、VirtualHost
および Directory
スタンザの外に置いてください。com.ibm.ejs.sm.adminServer.lsdPort=a_port_number
を追加して、
9000 以外のポートを使用するように管理サーバーを構成します。IBM HTTP Server を IBM Software Development Kit 1.3.0 および WebSphere Application Server とともにインストールして、IBM HTTP Server IKEYMAN ハードウェア暗号化メニュー・オプションを使用して鍵を定義しようとすると、表示されるウィンドウが見にくかったり、その中でナビゲートしにくかったりすることがあります。この問題を解決するには、該当するプラットフォームに合った対処方法を使用してください。
AIX:
$JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT
次の 1 行ステートメント (ここでは読みやすいように 2 行で示しています) で置き換えて変更する。
$JAVA_EXECUTABLE -Djava.ext.dirs=/usr/opt/ibm/gskkm/classes/ikmuser.properties $IKEYMAN_TEMP_JAVA_INPUT
Linux プラットフォーム:
$JAVA_EXECUTABLE $IKEYMAN_TEMP_JAVA_INPUT
次の 1 行ステートメント (ここでは読みやすいように 2 行で示しています) で置き換えて変更する。
$JAVA_EXECUTABLE -Djava.ext.dirs=/usr/local/ibm/gsk5/classes/ikmuser.properties $IKEYMAN_TEMP_JAVA_INPUT
WebSphere Application Server の管理サーバーを実行しているときに、サンプル・サーブレット・スヌープなどのサーブレットを実行しようとすると、サーバー・エラーが戻されます。 iPlanet プラグインがサーブレットを WebSphere Application Server に送信できるようにするには、以下のようにして iPlanet サーブレット・サポートをオフにします。
UNIX プラットフォームでは、ドミノ構成コードが実行されているときに、ドミノ・プラグイン構成障害に関するログが正しくない場合があります。 Domino Web Server Application Program Interface (DSAPI) プラグインがロードされていない場合は、手動でドミノ構成命令を使用して、構成のトラブルシューティングを行ってください。プラグインが適切にロードされているようであれば (つまり、ドミノ・コンソール始動メッセージで確認可能)、ログ・エラーは無視してかまいません。
Domino 6 Web サーバーは、GSK4 ライブラリーからリンクされるモジュールはロードしません。この問題を解決するには、Domino 6 Web サーバー用に、GSK5 ライブラリーを使用するプラグインを別に用意する必要があります。このプラグイン・ファイルは libdomino6_http.so です。 Domino 5.0.x Web サーバーでは、引き続き libdomino5_http.so プラグイン・ファイルを使用します。
すべてのオペレーティング・システム
AIX
PropertySessionReaperInterval は、新しいシステム・プロパティーです。このプロパティーは、セッション・マネージャー内の無効化スレッドのスリープ・インターバルを設定するのに使用できます。
このシステム・プロパティーの適用方法は、次のとおりです。
この方法の例は、次のとおりです。
Linux Red Hat 7.2 で Netscape 4.78 を使用する場合、および Solaris 8 で Netscape 4.7 を使用する場合は、Enter キーを使用して、
IBM Administration Server の「ログ」セクションで、
Directory Logging フォームを実行依頼することができます。Directory Logging フォームは、テキスト・フィールド「ヘッダー・フィールドに含まれる Cookie ドメイン (Cookie
domain to include in the header field)」の無効なデータを受け入れます。これは構成ファイルに CookieDomain ディレクティブを設定します。
IBM HTTP Server は、再始動中にエラーを表示します。CookieDomain ディレクティブに無効値を入力しないようにするには、そのフォームの「実行依頼 (Submit)」を使用してデータを実行依頼してください。
HTTP サーバー・ポートは、wscp を介して構成可能である (Defect PQ59624.RN)
デフォルトの HTTP サーバー・ポートは 9080 です。追加のアプリケーション・サーバーが作成される度に、次の増分番号 (たとえば、9081) を受け取ります。1 つの物理ノード上に複数の WebSphere Application Server インスタンスがインストールされている場合、ポート番号の構成は重要です。各インスタンスには、HTTP トランスポート・ポートの開始ポート番号が割り当てられます。wscp コマンドは次の通りです。 wscp> Node modify /Node:myNode1/ -attribute {{LastUsedPort 9100}} ここで、myNode1 は、WebSphere Application Server がインストールされているノードで、9100 は増分の開始されるポート番号です。
IBM HTTP Server バージョン 2.0 のアンインストール中、切り捨てられてメッセージを持つポップアップ・ウィンドウが表示されます。このテキスト・メッセージは次のようになります。
/opt/IBMIHS/conf/httpd.conf.sample はこのシステムに存在しており、 インストール以降に変更されています。 このファイルを除去しますか?
IBM HTTP Server バージョン 2.0 は、サポートされるすべてプラットフォーム上で使用できるようになりました。新規 Apache 2.0 Web サーバーを基に、 IBM HTTP Server のこのバージョンには Apache 2.0 の基礎 (バージョン 2.0.42)、 IBM で追加した InstallShield MultiPlatforms インストール、Secure Sockets Layer (SSL)、および Lightweight Directory Access Protocol (LDAP) が組み込まれています。 IBM HTTP Server バージョン 2.0 は、WebSphere Application Server バージョン 4.0.5 と共に配置された場合、IBM によって完全にサポートされています。IBM HTTP Server バージョン 2.0 は、 http://www-3.ibm.com/software/webservers/httpservers/ からダウンロードすることができます。
IBM HTTP Server バージョン 2.0 をインストールする:
ダウンロードしたファイルをアンパックしたディレクトリーに移動して、次のコマンドを発行してください。
java -jar setup.jar
XWindow を使用せずに IBM HTTP Server バージョン 2.0 を UNIX にインストールしたい場合は、次のようにします。
java -jar setup.jar -silent
java -jar setup.jar -console
IBM HTTP Server バージョン 2.0 を WebSphere Application Server バージョン 4.0.5 とともにセットアップする
IBM HTTP Server バージョン 2.0 を WebSphere Application Server バージョン 4.0.5 とともに使用するには、IBM HTTP Server 2.0 httpd.conf ファイル (サーバー・ルートの下の conf ディレクトリーにある) を見つけ、 HTTP トランスポート・プラグインが IBM HTTP Server バージョン 2.0 で正しく機能するように、次のディレクティブを追加してください。
LoadModule was_ap20_module /full/path/to/module WebSpherePluginConfig /full/path/to/config
WebSphere Application Server バージョン 4.0.5 が IBM HTTP Server バージョン 2.0 と同じマシン上にインストールされている場合:
モジュールへのパス:
Windows NT と Windows 2000: C:\<WASROOT>\bin
Linux: <WASROOT>/bin
Linux 390: <WASROOT>/bin
Solaris オペレーティング環境: <WASROOT>/bin
AIX: <WASROOT>/bin
HP: <WASROOT>/bin
WebSphere プラグイン構成ファイル (plugin-cfg.xml) へのパス:
Windows NT と Windows 2000: C:\<WASROOT>\config
Linux: <WASROOT>/config
Linux 390: <WASROOT>/config
Solaris オペレーティング環境: <WASROOT>/config
AIX: <WASROOT>/config
HP: <WASROOT>/config
WebSphere Application Server バージョン 4.0.5 を IBM HTTP Server バージョン 2.0 とは別のマシン上にインストールする (リモート構成):
IBM HTTP Server バージョン 2.0 を WebSphere Application Server バージョン 4.0.5 のインストールされていないマシン上にインストールする場合は、WebSphere
Application Server バージョン 4.0.5 のインストールされているマシンから 2.0 ベースの WebSphere Application Server プラグインが必要です。
WebSphere Application Server バージョン 4.0.5 のインストーラーは、2.0 ベースの
WebSphere Application Server プラグインを、
(すべてのモジュールが常駐する) WebSphere Application Server サーバー・ルートの bin ディレクトリーにインストールします。2.0 ベースの WebSphere
Application Server プラグインのファイル名は mod_was_ap20_http.dll
(Windows プラットフォームの場合)、または mod_was_ap20_http.so (UNIX または
Linux プラットフォームの場合) です。2.0 ベースの WebSphere Application Server
プラグインは、IBM HTTP Server バージョン 2.0 がインストールされているマシンにコピーする必要があります。2.0 ベースの WebSphere Application Server プラグインは、
IBM HTTP Server モジュールと同じディレクトリーに入れることをお勧めします。
Windows NT と Windows 2000: C:\Program Files\IBM HTTP Server 2.0\modules
Linux: /opt/IBMIHS/modules
Linux 390: /opt/IBMIHS/modules
Solaris オペレーティング環境: /opt/IBMIHS/modules
AIX: /usr/IBMIHS/modules
HP: /opt/IBMIHS/modules
Windows プラットフォームでは、plugin_common.dll ファイル (32 ビットの共通プラグイン・ライブラリー) も、IBM HTTP Server バージョン 2.0 がインストールされているマシンにコピーしなければなりません。このファイルは、IBM HTTP Server モジュールと同じディレクトリーに入れてください。
Windows プラットフォーム: C:\Program Files\IBM HTTP Server 2.0\modules\plugin_common.dll
また、ターゲットの WebSphere Application Server バージョン 4.0.5 サーバーに対応する
WebSphere Application Server plugin-cfg.xml ファイルも
IBM HTTP Server バージョン 2.0 がインストールされているマシンにコピーする必要があります。
WebSphere Application Server バージョン 4.0.5 plugin-cfg.xml ファイルは、
IBM HTTP Server 構成ファイルが置かれているのと同じディレクトリーに入れることをお勧めします。以下は、WebSphere Application Server plugin-cfg.xml 構成ファイルへの推奨パスです。
Windows NT と Windows 2000: C:\Program Files\IBM HTTP Server 2.0\conf
Linux: /opt/IBMIHS/conf
Linux 390: /opt/IBMIHS/conf
Solaris オペレーティング環境: /opt/IBMIHS/conf
AIX: /usr/IBMIHS/conf
HP: opt/IBMIHS/conf
plugin-cfg.xml ファイルを IBM HTTP Server バージョン 2.0 マシンにコピーした後は、IBM HTTP Server バージョン 2.0 マシン上の有効なパスを指すように、plugin-cfg.xml を編集する必要があります。以下に例を示します。
<Log LogLevel="Error" Name="/opt/WebSphere/AppServer/logs/http_plugin.log"/>
/opt/WebSphere/AppServer/logs/http_plugin.log というパスは、 IBM HTTP Server 2.0 マシン上で有効でなければなりません。
WebSphere Application Server バージョン 4.0.5 上で SSL がセットアップされている場合は、 plugin-key.kdb ファイルと plugin-key.sth ファイルを WebSphere Application Server バージョン 4.0.5 マシンから IBM HTTP Server バージョン 2.0 マシンにコピーして、 IBM HTTP Server バージョン 2.0 マシン上の適切なパスを指すように、 plugin-cfg.xml ファイルを編集する必要があります。以下に例を示します。
<Property name="keyring" value="/opt/WebSphere/AppServer/etc/plugin-key.kdb"/> <Property name="stashfile" value="/opt/WebSphere/AppServer/etc/plugin-key.sth"/>/opt/WebSphere/AppServer/etc/plugin-key.kdb および /opt/WebSphere/AppServer/etc/plugin-key.sth というパスは、 IBM HTTP Server 2.0 マシン上の有効なパスでなければなりません。
AIX 5.2.0 で IBM HTTP Server 2.0.42.1 を始動しようとすると、次のようなエラー・メッセージが出ることがあります。
[crit] (78) A remote host did not respond within the timeout period.: alloc_listner: failed to set up sockaddr fo :: Syntax error on line 130 of /usr/IBMIHS/conf/httpd.conf Listen setup failed.
/etc/netsvc.conf ファイルがこのエラー・メッセージの原因になっている可能性があります。このファイルのデフォルト・バージョンでは、すべての行がコメント化されています。 hosts 行のコメントが外されて hosts = local = auth , bind のようになっていると、問題が生じる場合があります。
この問題を解決するには、次のいずれかの方法を取ります。
hosts = local = auth , bind , local
64K を超えるポスト・データを持つ要求を実行すると、Domino 6.0.1 Web サーバーが破損します。 Lotus はこの症状をバグと認識しています。Lotus SPR 番号は DMEA5MRKJH です。この問題のホット・フィックスを受け取るには、Lotus の発生事象レポートを開く必要があります。
HTTP サーバーの取り扱いに戻る
起こり得る問題と推奨される修正方法に戻る
ご使用のデータベースに関する問題および修正方法を参照してください。
このリリースでサポートされている新規 Data Direct ConnectJDBC 3.1
JDBC ドライバーを使用する場合、selectMethod=cursor 構成パラメーターは必要なくなりました。ConnectJDBC 3.x ドライバーには、
selectMethod=direct モードを使用したトランザクション操作のサポートが追加されました。ほとんどの場合、selectMethod=direct は、
ConnectJDBC 2.2 ドライバーに必要な selectMethod=cursor モードよりも高パフォーマンスを示します。
DB2
DB2 バージョン 8.1 には、新しい汎用の Java Database Connectivity (JDBC) タイプ 4 ドライバーに対するサポートが追加されています (クラス名は com.ibm.db2.jcc.DB2ConnectionPoolDataSource)。これは、DB2 の以前のリリースで使用できる既存のタイプ 2 およびタイプ 3 に追加されたものです。これまでの JDBC ドライバーと汎用ドライバーの違いについては、次のリンクを参照してください。
http://www-3.ibm.com/software/data/db2/udb/ad/v8/client/db2a1305.htm
WebSphere Application Server バージョン 4.0.6 には、タイプ 4 モードのみの汎用ドライバーに対するサポートが追加されています。このドライバーを使用するには、driverType プロパティーを 4 に設定する必要があります。このドライバーに必要なプロパティーは、serverName、portNumber、 driverType、および databaseName です。 StaleConnectionExceptions が正しく変換されるようにするためには、最低でも DB2 8.1 FP 2 を使用する必要があります。
汎用ドライバーは最適化をサポートし、この最適化によって、 JDBC ドライバーが準備済みステートメントの作成を実行時まで延ばすことができるようになります。このため、作成と実行をサーバーに対する単一要求として結合することができ、それによってネットワークの遅延が軽減されます。ただし、この最適化の副次作用として、 setBinaryStream() メソッドまたは setBlob() メソッドを使用する準備済みステートメントを実行しようとすると SQL0301N 例外が発生します。汎用ドライバーで setBinaryStream() または setBlob() を使用するアプリケーションでは、プロパティー deferPrepares を false に設定して作成の遅延を使用不可にする必要があります。
WebSphere Application Server 管理サーバーは、準備済みステートメント上で setBinaryStream() メソッドおよび setBlob() メソッドを使用するため、汎用 JDBC ドライバーを使用するときには、<WAS_HOME>/bin/admin.config ファイルで、 deferPrepares プロパティーを false に設定する必要があります。 admin.config ファイルには、以下のプロパティーが含まれています。
com.ibm.ejs.sm.adminServer.dbdataSourceClassName=com.ibm.db2.jcc.DB2ConnectionPoolDataSource com.ibm.ejs.sm.adminServer.dbserverName=<serverName> com.ibm.ejs.sm.adminServer.dbportNumber=<portNumber> com.ibm.ejs.sm.adminServer.dbdriverType=4 com.ibm.ejs.sm.adminServer.dbdeferPrepares=false com.ibm.ejs.sm.adminServer.dbdatabaseName=<databaseName> com.ibm.ejs.sm.adminServer.dbuser=<user> com.ibm.ejs.sm.adminServer.dbpassword=<password> com.ibm.ejs.sm.adminServer.dbdisable2Phase=true
リモートで DB2 にアクセスするネット・ドライバーは、このバージョンの WebSphere Application Server ではサポートされていません。リモートで DB2 を使用している場合は、admin.config ファイルの dbServerName および dbPortNumber フィールドを変更しないでください。リモートで DB2 にアクセスするために、DB2 クライアント・インストールおよび DB2 別名の使用がサポートされています。
DB2 を UNIX プラットフォームで実行した場合、次のエラー・メッセージが表示されることがあります。
java.lang.NoSuchFieldError: batchReturn
このエラーは、db2java.zip ファイルのミスマッチが原因で発生します。この問題を回避するには、必ずクラスパスで、Java12 ディレクトリーの
db2java.zip ファイルを、
Java ディレクトリーの db2java.zip よりも前に指定してください。よくある問題は、~db2inst1/sqllib/java12/db2java.zip
と指定すべきところで ~db2inst1/sqllib/java/db2java.zip
を使用して Java Database Connectivity (JDBC) ドライバーをインストールしてしまうことです。
IBM Toolbox for Java (AS/400 Toolbox for Java とも呼ばれる) Java Database Connectivity (JDBC) ドライバーを WebSphere Application Server バージョン 4.0.x と一緒に使用する場合は、IBM Toolbox for Java 修正レベル 4 (5722JC1 または JTOpen) の最新のバージョンを使用する必要があります。ライセンス交付を受けた製品 5722JC1 をインストールしている場合は、 5722JC1 フィックスパック SI02195 も適用しなければなりません。フィックスパック の適用後、WebSphere Application Server バージョン 4.0.x を実行しているワークステーション・システムの Toolbox JAR ファイル (jt400.jar) を、 iSeries システムの更新バージョンに置き換えてください。
Solaris 8 オペレーティング環境で、DB2 UDB データベースをリポジトリーとして WebSphere Application Server を使用している場合、システムでハング状態が発生することがあります。このハング状態は、Solaris オペレーティング環境のネットワーク障害が原因で発生します。この条件を修正するには、以下のようにします。
特定のシステムにより、1 つ、2 つ、またはこの 3 つすべてのソリューションが必要な場合があります。
Informix Database Server の配置時に WebSphere Application Server によって作成されるテーブル構文は、Informix 用のデフォルトのロック機構を使用して作成されます。デフォルトは、「ページ固定」です。オンライン・トランザクション処理 (OLTP) アプリケーションの場合、ユーザーは行ロックを要する特定のテーブルを識別し、それを手作業で変更する必要があります。
ご使用の WebSphere Application Server の構成で WLM が使用可能になっていて、Informix バージョン 7.31 を使用していて、かつサーバー・グループを使ってアプリケーションがインストールされている場合、以下のいずれかを行うと重大度 1 の例外がスローされます。
管理コンソールのメッセージ域に例外のメッセージが表示され、その例外に関する詳細情報がトレース・ファイルと activity.log ファイルに書き込まれます。メッセージは、以下のようなものです。
[01.12.13 13:42:02:925 CST] 3b3402 ExceptionUtil X CNTR0019E: メソッド作成処理中に 非アプリケーション例外が発生しました: java.rmi.RemoteException: ; (Non-application exception occurred while processing method create: java.rmi.RemoteException: ;) ネストされた例外は、以下のとおりです: (nested exception is:) java.sql.SQLException: 新しい行を挿入できません - UNIQUE INDEX 列の値が重複しています。 (java.sql.SQLException: Could not insert new row - duplicate value in a UNIQUE INDEX column.)
[01.12.13 13:42:02:962 CST] 3b3402 ExceptionUtil X CNTR0020E: Bean BeanId(admin#nssrcm.jar#NsSession, null) でのメソッド・バインド処理中に非アプリケーション例外が発生しました: (Non-application exception occurred while processing method bind on bean BeanId(admin#nssrcm.jar#NsSession, null):) org.omg.CORBA.portable.UnknownException: マイナー・コード: 0 完了: com.ibm.ejs.ns.CosNaming.EJBDataStore.bind(EJBDataStore.java:206) と予想される (minor code: 0 completed: Maybe at com.ibm.ejs.ns.CosNaming.EJBDataStore.bind(EJBDataStore.java:206))
org.omg.CORBA.TRANSACTION_ROLLEDBACK: com.ibm.ejs.csi.TranStrategy.handleException(TranStrategy.java:121) での com.ibm.websphere.csi.CSITransactionRolledbackException。 (com.ibm.websphere.csi.CSITransactionRolledbackException at com.ibm.ejs.csi.TranStrategy.handleException(TranStrategy.java:121))
これらのメッセージは、無視してください。サーバー・クローンとアプリケーションは正常に実行されます。
Oracle シン・ドライバーおよび OCI ドライバーを使用している場合、照会を括弧 ("()") で囲むと、エラー「ORA-01009: 必須パラメーターが欠落しています (ORA-01009: missing mandatory parameter)」になり、結果セットが空 (データなし) になります。これは Oracle のエラー (917674) であり、817.2 fixset で修正されました。この問題を避けるには、Oracle fixset 817.2 をインストールするか、照会を括弧で囲まないようにします。
Solaris オペレーティング環境または Linux プラットフォーム上で Oracle に接続プールを使用している場合、ユーザーごとにオープンできる最大ファイル数を、最小でも 2048 に設定することをお勧めします。これは、ulimit コマンドを使用して実行できます。アプリケーション・サーバーを実行しているセッションに、
ulimit -n 2048
と入力してください。
また、Linux システムでは、Java 仮想マシン (JVM) の初期ヒープ・サイズと最大ヒープ・サイズをそれぞれ 256 MB と 512 MB に設定しておくことをお勧めします。
管理インターフェースを使用して、「ノード」>
node_name >「アプリケーション・サーバー」>
server_name >「プロセス定義」>「
JVM 設定」の順に選択します。「初期ヒープ・サイズ )」フィールドに 256
と入力し、「
最大ヒープ・サイズ)」フィールドに 512
と入力します。この構成を保管して、設定が有効となるようにアプリケーション・サーバーを再始動してください。
WebSphere Application Server のテスト中、Oracle は 2 つの異なる物理 XA 接続を使用して同じ Oracle インスタンスを開くことができません。この問題により次の例外が発生します。
Oracle 9i: XAER_RMERR resource error -3
Oracle 8i: ="Io exception: End of TNS data channel", SQLState=null, vendorCode=17002)
この問題を解決するために、Oracle でバグ (2511780) がオープンされています。この Oracle のバグについては、Oracle または IBM のサポートまで連絡してください。
Sybase を管理リポジトリーとして使用している場合に、以下の DatabaseMetaData メソッドは、最新の Sybase EBF では実装されておらず、UnimplementedOperationExceptions をスローします。
getSchemaName() getTableName() getCatalogName()
Sybase をインストールして使用するときは、必ず最新の EBF を適用し、 EBF# (EBF# は使用可能な最新 fix の番号) に含まれているパッチと拡張機能がリストされた、付属の Cover.ROLL.EBF# 文書を見つけてください。特に、以下の EBF ID を探してください。
1074408-11 CR255096 1074408-12 CR255094 1074408-13 CR255097
データ・ソースの作成中に「テスト接続」をクリックすることで、処理の前に、データ・ソースが正しくセットアップされているかどうかを調べることができます。データ・ソースが Sybase 用のものである場合、「テスト接続」をクリックすると、接続がすでにクローズしたことを示す JZ0C0 エラーが戻される場合があります。この問題が発生した場合は、Sybase EBF 9422 またはそれ以降のリリースをインストールしなければなりません。ただし、JZ0C0 エラーが出ても、管理サーバーおよびアプリケーション・サーバーは 9422 より前のリリースの EBF で正しく作動します。
管理コンソールの始動時、あるいは XMLConfig 管理用タスクの実行時には、 10 から 30 分の時間が必要です。その理由は、管理サーバーが呼び出しを行って、管理コンソール・ツリーを埋めたり、XMLConfig をエクスポートしたりするのに使用するリポジトリー・データを検索する場合、リモートの 64 ビット Oracle 9 データベース・サーバーからの応答を 30 秒間待機するためです。
管理リポジトリーの問題を回避するため、あるいはアプリケーションでのパフォーマンス上の問題を解決するためには、32 ビット Oracle 9i R1 または Oracle 9i R2 (64 ビットまたは 32 ビット) のどちらかを使用してください。
同じマシン上に複数のアプリケーション・サーバーのクローンがある ServerGroup 環境で、 Java クライアント・プログラムを実行しようとすると、次のエラーが表示される場合があります。
クライアント・ウィンドウ:
- Java.rmi.MarshallException: CORBA Comm_Failure 1 Maybe: - org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: maybe - at com.ibm.CORBA.iiop.IIOPConnection .purge_calls - at com.ibm.CORBA.iiop.StandardReaderThread.run
この一連のエラーは、クローン化されたアプリケーション・サーバーが失敗するごとに生じます。
クライアント・ログ:
- WWLM0019: Method getNextClone found no usable proxies in the list.
クローンの失敗後に行われる後続のクライアント要求ごとに、上記のいずれかのメッセージが表示されます。
WebSphere Application Server のトレース・ファイル: すべてのクローンが再始動されたことを知らせるメッセージが表示されます。
$WAS_HOME/bin directory 内で、core file が生成されたことが分かります。hs_err_pidxxxx.log file が、失敗したクローン化アプリケーション・サーバーごとに作成されます。
これを回避するには、.hotspot_compiler という名前のファイルを $WAS_HOME/bin ディレクトリーに作成し、そのファイルに次のストリングを追加します。 exclude com/ibm/ws/wlm/util/RIHelper removeServiceContext
クライアント・サイドとサーバー・サイドのコンポーネントで構成されるアプリケーションが同じ Java 仮想マシン (JVM) を共用するアプリケーション・サーバーに配置されている場合、クライアント・サイドのコンポーネントをロードするクラス・ローダーはサーバー・サイドのコンポーネントをロードするクラス・ローダーと同じである必要があります。そうでない場合、次のメッセージと共に、 org.omg.CORBA.BAD_PARAM orb エラーが表示されることがあります。
サーバントが予想した型ではありません ("Servant is not of the expected type")
このエラーを回避するには、クライアント・サイドとサーバー・サイドのコンポーネント間でクラス・ローダーを共用する必要があります。これを実現する 1 つの方法は、com.ibm.ws.classloader.classSharing=true プロパティーを設定することです。インフォセンターに、クラス・ローダーの可視性と共用の関連トピックの詳細があります。
Java 仮想マシン (JVM) のプロパティー com.ibm.ws.classloader.classSharing=false を指定する場合、 2 つの追加 JVM プロパティーを指定する必要があります。
プロパティーを追加するには、次のステップを実行してください。
上記のステップの実行後に、-Dcom.ibm.CORBA.notLocal=true を設定すると、パフォーマンスに影響があります。
notLocal とは、クライアントとサーバーは、同じアプリケーション・サーバーに配置できますが、互いにリモートとして扱われることを意味します。
notLocal を true に設定することは、クライアント・アプリケーション
(JSP ファイルまたはサーブレット) を 1 つのアプリケーション・サーバーに配置し、サーバー・アプリケーション (Enterprise Bean) を別のアプリケーション・サーバーに配置することと同じです。
汎用 Java Message Service プロバイダーは 2 フェーズ・コミット WebSphere トランザクションをサポートしない (Defect PQ67210.RN)
WebSphere Application Server バージョン 4.0 では、 2 フェーズ・コミットメント・トランザクションは、 MQSeries JMS プロバイダー用の Java Message Service (JMS) ラッパーを介してのみサポートされています。汎用 JMS プロバイダーは外部 Java Naming and Directory Interface (JNDI) ルックアップを介してサポートされていますが、ラップされていないため、 2PC トランザクションには参加できません。
このフィックスはスタンドアロンの汎用 JMS リソース・バインディング・ユーティリティーを提供します。その目的は、実際の汎用プロバイダー・リソースへの間接参照を持つ、 WebSphere のラップされた JMS リソースをバインドすることです。これにより、ラップされた JMS リソースをアプリケーション・サーバー内で使用でき、またラップされているため、2 フェーズの WebSphere トランザクション内に参加できるようになります。WebSphere JMS ランタイムでは、これらのリソースのサポートが使用可能になっており、フェイルオーバーした場合はリカバリーすることができます。
汎用 JMS リソース・バインダーの構文:
<install_root>\java\bin\java -cp <install_root>\lib\resources.jar;<naming_jars>; com.ibm.ejs.jms.generic.GenericJMSBinder <WASICFactory> <WASNameSpaceURL> <InternalJndiName> <ExternalICFactory> <ExternalProviderURL> <ExternalJndiName> <QCF/TCF>
ラップされた JMS 接続ファクトリーがバインドされるネーム・スペースの初期コンテキスト・ファクトリー。これは通常、次のいずれかになります。
WebSphere Application Server ネーム・スペース: com.ibm.websphere.naming.WsnInitialContextFactory
ファイル・システム: com.sun.jndi.fscontext.RefFSContextFactory
ラップされた JMS 接続ファクトリーをバインドする WebSphere Application Server ネーム・スペースのプロバイダー URL。
ラップされた JMS 接続ファクトリーがバインドされる JNDI 名。
汎用 JMS プロバイダー・リソース・ネーム・スペースの初期コンテキスト・ファクトリー。
汎用 JMS プロバイダー・リソースがバインドされるプロバイダー URL。
外部ネーム・スペースでの汎用 JMS 接続ファクトリーの JNDI 名。
外部ネーム・スペースでの汎用 JMS 接続ファクトリーのキューまたはトピック型。
SuSE 7.0 Linux 390 での WebSphere Application Server の負荷テスト中に、メモリー・リークが観察されます。このメモリー・リークが原因で、使用可能な Java 仮想マシン (JVM) のヒープ・ストレージとシステム・メモリーの消費が激しくなり、その結果、java.lang.OutOfMemory エラーがアプリケーション・サーバーに表示されて、アプリケーション・サーバーが再始動されます。
この問題は、WebSphere Application Server に同梱された IBM Software Development Kit のオブジェクト・リクエスト・ブローカー・コンポーネントで識別されています。
この問題を回避するには、すべてのプラットフォームで使用可能な fix PQ69054 を適用してください。
Java プログラミング
起こり得る問題と推奨される修正方法に戻る
非活性化された Session Bean を新規 admin.config ディレクティブとして保管できるディレクトリーを指定することができます。
Stateful Session Bean は非活性化されて、
<install_root>/bin ディレクトリーに保管されます。これはカスタマイズすることができます。新規ディレクティブは、
com.ibm.ejs.sm.adminServer.containerStatefulSessionBeanPassivationDir=<directory name> です。
DB2/390 でセッション・パーシスタンスが失敗する (Defect 164349.RN)
DB2 8.1 クライアント (フィックスパック を含む) を DB2/390 V7 サーバーに接続してセッション・パーシスタンスを使用していると、持続セッションを使用してアプリケーション・サーバーを始動しようとするときに、 std_err ログに次のようなエラーが記録されることがあります。
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2] SQL0440N No authorized routine named "SQLCOLUMNS" of type "" having compatible arguments was found. SQLSTATE=42884
このエラーが出た場合は、DB2/390 の管理者に DB2 フィックスパック UQ72083 を適用するよう依頼してください。 DB2 フィックスパック についてご質問がある場合は、DB2 サポートにご連絡ください。
セッションの取り扱いに戻る
起こり得る問題と推奨される修正方法に戻る
次のシナリオでは、直列化の例外により、値による受け渡し (Pass-by-value) 呼び出しが失敗しました。
この問題を回避するには、WebSphere Application Server バージョン 3.5.6、WebSphere Application Server バージョン 4.0.3、および WebSphere Application Server zSeries 4.0.x 間の互換性モードを実装するために、新しいシステム・プロパティー -Dcom.ibm.websphere.container.portable を配置してください。さらに、ファインダー・メソッドによって戻される Enumeration と Collection の使用について、追加の検査が行われます。詳細については、Defect 110799.RN を参照してください。
ご使用のアプリケーションに、上記のシナリオのいずれかでインターオペラビリティーの問題がある場合を除いて、このプロパティーを使用可能にしないでください。
WebSphere Application Server バージョン 4.0.4 で、そのサーバーに対する C++ クライアントがある場合、このプロパティーを使用可能にしないでください。
WebSphere Application Server バージョン 3.5.x で、サーバーに対するすべてのクライアントが WebSphere Application Server バージョン 3.5.6 以上である場合、または WebSphere Application Server バージョン 4.0.x では、サーバーに対するすべてのクライアントが WebSphere Application Server バージョン 4.0.4 以上である場合を除き、 WebSphere Application Server バージョン 3.5.6 または WebSphere Application Server V4.0.4 でこのプロパティーを使用可能にしないでください。
WebSphere Application Server for zSeries の資料を調べて、その環境に対する正しいインストール手順を確認してください。そうしないと、直列化エラーによって例外がスローされます。
WebSphere Application Server バージョン 3.5.6 でプロパティー com.ibm.websphere.container.portable=true が設定された後、次の制限が引き続き適用されます。
これらのフィックスは、波状に適用されるように設計されています。 com.ibm.websphere.container.portable プロパティーをオンにする前に、このサーバーのすべてのクライアントが WebSphere Application Server バージョン 3.5.6 または WebSphere Application Server バージョン 4.0.4 であることを確認してください。
そのためには、まずクライアント・マシンを更新してから、サーバーを更新することができます。最後に、構成が設定されるときに、そのプロパティーと新しい機能を使用可能にして、アップグレードのためのネットワーク全体のシャットダウンを回避することができます。
このプロパティーを設定する手順は、次のとおりです。
WebSphere Application Server バージョン 3.5.6 で、次の手順を実行します。
WebSphere Application Server バージョン 4.0.4 で、次の手順を実行します。
前述の条件を持つインターオペラビリティーの問題がない場合は、使用するサーバーでこのプロパティーをオンにしないでください。
WebSphere Application Server の Enumeration と Collection は、それらが作成されたトランザクション以外では使用できません。プロパティー com.ibm.websphere.container.portable を使用可能にした後、2 つのトランザクションが、同じ Enumeration または Collection インスタンスにアクセスしようとするかどうかを判別するために、追加の検査が行われます。
万が一この状態が発生した場合は、EnumeratorException がスローされます。
さらに、トランザクションが終了した後、遅延コレクションまたは列挙型がサーバーから切断されます。トランザクションの終了後に enumeration または collection がサーバーに接触して追加のエレメントにアクセスしようとすると、 com.ibm.ejs.container.finder.CollectionCannotBeFurtherAccessedException がスローされます。
インターオペラビリティーに戻る
起こり得る問題と推奨される修正方法に戻る
該当する言語に関する問題および修正方法を参照してください。
デフォルト構成とサンプル構成の情報が含まれたデータ・ファイルは、このリリースでは翻訳されていません。例えば、Default Server や Sample DB Driver などのオブジェクトは、英語以外のロケールでも英語の名前を持ち、英語で記述されています。
バッチ・ファイルおよびシェル・スクリプトからの
echo
ステートメント (ejbdeploy
や adminclient
など)
も翻訳されません。
この WebSphere Application Server のリリースで提供されている、アプリケーション・クライアント (J2EE (Java 2 Enterprise Edition) クライアントと Java シン・クライアント) のインストールは英語 (en_US) 版のみです。
AIX 上で、韓国語およびその他の言語で、一部の WebSphere Application Server ページが正しく表示されないことがあります。このページ表示を修正するには、 Microsoft Internet Explorer では、 「表示」>「エンコード」メニュー・オプションの「 自動選択」を選択解除し、 Netscape ブラウザーの「表示」>「文字セット」 オプションを選択解除してください。
WebSphere Application Server for Linux on zSeries (390) アドバンスド版を Linux for z390 配布版にインストールする前に、ご使用の 2 バイト文字セット (DBCS) ロケールの配布版で True Type フォント と 入力方式 が使用可能であることを確認してください。
WebSphere Application Server for Linux on zSeries バージョン 4.0.1 およびバージョン 4.0.2 の CD-ROM を持っている場合は、以下の操作を実行すると、リモートから管理クライアントにアクセスできます。
adminclient host_name_of_Linux_on_zSeries_machine
Turbo Linux 6.5 for z390 の配布版では、DBCS はサポートされないことに注意してください。
サポートされている 2 バイト文字セット (DBCS) ロケールの 1 つを使用している場合は、以下のファイル・セットの 1 つが必要です。
AIX:
X11.fnt.ucs.ttf (for ja_JP or Ja_JP) X11.fnt.ucs.ttf_CN (for zh_CN or Zh_CN) X11.fnt.ucs.ttf_KR (for ko_KR) X11.fnt.ucs.ttf_TW (for zh_TW or Zh_TW)
Solaris オペレーティング環境:
SUNWjxcft, SUNWjxmft (for ja) SUNWkcoft (for ko) SUNWgttf (for zh_GBK) SUNW5ttf (for zh_TW.BIG5)
Lightweight Directory Access Protocol (LDAP) の拡張プロパティー・サポートのヘルプ・ファイルのドイツ語版はバックレベルです。最新レベルを入手するには、インフォセンターの項目『6.6.18.0.9: LDAP の拡張プロパティー・サポート』を参照してください。製品のインターフェースからアクセス可能なファイル・レベルを訂正するには、 product_installation_root/web/InfoCenter/was/060618009.html にあるヘルプ・ファイルのバージョンを置換してください。たとえば、Windows NT プラットフォームでは C:\WebSphere\AppServer となります。
AIX マシン上で WebSphere Application Server を実行している場合、文字が正しく表示されるためには、True Type フォント (TTF) がインストールされていなければなりません。これらのフォントは、AIX のデフォルトのインストールでは、自動的にはインストールされません。
クラス名に非ラテン文字を使用すると、org.omg.CORBA.NO_IMPLEMENT error が生じます。
サーバー・サイドの Enterprise Bean のクラス名に非ラテン文字が含まれているときに、クライアントが呼び出そうとするリモート・メソッドに、非ラテン文字をロードするクラス名を持つクラスが必要である場合、クライアント・プログラムは次のエラーを受け取ります。
java.rmi.ServerException: RemoteException occured in server thread; nested exception is: java.rmi.RemoteException: org.omg.CORBA.NO_IMPLENT: Unable to locate value class <DBCS class name>
この問題を回避するには、クラスの名前を変更して、クラス名にラテン文字がないことを確認してください。アプリケーションを再生成し、再配置してください。
WebSphere Application Server アドバンスド・シングル・サーバー版を Solaris オペレーティング環境 (中国語 (簡体字) のみ) にインストールする場合、管理コンソール上での文字の破損を避けるために、converter.properties ファイル内の GB2312 キーを Cp1386
から GBK
に変更してください。
converter.properties ファイルは、WebSphere/AppServer/properties
ディレクトリーにあります。
UNIX 上にインストールするとき、IBM Software Development Kit 1.3 製品の制約により、中国語 (繁体字) の文字が一部正しく表示されません。いくつかの文字は正しく表示されないか、読めません。
各国語版の問題/制約事項に戻る
起こり得る問題と推奨される修正方法に戻る
Xalan バージョン 2.2 は、WebSphere Application Server バージョン 4.0.3、バージョン 4.0.4、およびバージョン 4.0.5 に同梱されています。Xalan バージョン 2.2 のパフォーマンスはバージョン 2.1 より遅く、バージョン 2.1 の 3 倍から 5 倍多くのメモリーを使用します。詳細については、fix PQ68660 を参照してください。
次のメソッド呼び出しには、かなりの時間がかかります。
LotusXSL 2.2 で導入された DTM モデルが原因で、若干のパフォーマンスのオーバーヘッドがあります。
ガーベッジ・コレクター (GC) は、LotusXSL 2.2 以上のバージョンを WebSphere Application Server バージョン 4.0.3 以上と共に使用した場合、空きメモリー量が低下することを報告しています。GC は、同じ環境で LotusXSL 2.0 を使用した場合には、空きメモリー量が増えることを報告しています。メモリー使用量が増加するかどうかは、アプリケーションに依存します。
注: ご使用のアプリケーションが WebSphere Application Server に同梱された Xalan に依存している場合、前述の問題が懸念されます。それ以外では、パフォーマンス問題は、 Apache Web サイトからの Xalan の最新バージョンで処理されています。
前提製品の制約事項に戻る
起こり得る問題と推奨される修正方法に戻る
インフォセンターの項目『6.6.13.0: トランスポートのプロパティー』にある次の情報は、正しくありません。
このプロパティーの値は、最初のトランスポートで指定した後は、この管理可能ドメイン内の他のすべての HTTP トランスポートにグローバルに適用されます。