この章では、Sun Java System Application Server Platform Edition 8.2 製品に関する既知の問題とそれに関連する回避策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この節は次の項目から構成されています。
デフォルトでは、asenv.conf によってポイントされる domain1 の AS_ACC_CONFIG 変数のハードコードされた値が $INSTALL/lib/package-appclient.xml にあります。domain1 を削除して新たなドメインを作成した場合、AS_ACC_CONFIG 変数は新たなドメイン名で更新されません。その結果、package-appclient スクリプトの処理が失敗します。
次のいずれかを行います。
domain1 はそのままにしておき、その前後に別のドメインを作成します。
domain1 を削除し、$INSTALL/lib/package-appclient.xml の domain1 にハードコードされた値を新しいドメイン名で置き換えます。domain1 がない場合、新たなドメインが作成されるたびにこれを行う必要があります。
同一の Application Server インストール上では、backup-domain コマンドと restore-domain コマンドを使用してドメインをミラーリングできません。これは、asadmin restore-domain コマンドにドメイン名を変更するオプションがあっても、元の名前ではなく、別の名前でドメインを復元できないからです。バックアップされたドメインの名前を正常に変更したように見えても、名前を変更されたドメインの起動は失敗します。ドメイン設定のエントリは変更されておらず、startserv および stopserv は元のドメイン名を使用してパスを設定するからです。
restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.2 の backup-domain コマンドと restore-domain コマンドが動作するのは、同一マシンで同一ドメインをバックアップおよび復元する場合だけです。
J2SE 1.4.x、5.0、またはそれ以降のバージョンは、Application Server で設定できます。J2SE 5.0 プラットフォームの重要な特徴は、JMX エージェントを起動できることです。サーバーの起動時にシステムプロパティーを明示的に設定すると、JMX エージェントがアクティブになります。
次に例を示します。
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false"
JMX プロパティーを設定してサーバーを起動すると、Application Server VM 内で新しい jmx-connector サーバーが起動します。この場合は、望ましくない副作用の 1 つとして、管理機能が悪影響を受け、Application Server の管理 GUI や CLI で予期しない結果が発生することがあります。問題は、組み込みの jmx-connector サーバーと新たな jmx-connector サーバーとの間で衝突が発生することにあります。
jconsole または何らかの JMX 互換クライアントを使用する場合には、Application Server とともに起動する標準の JMX コネクタサーバーを再利用することを検討してください。
サーバーの起動時に、次に示すような行が server.log に作成されます。ここで指定されている JMXServiceURL に接続し、資格を正常に指定した後、同様の管理および設定操作を実行することができます。次に例を示します。
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise. system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#]
詳細については、『 Sun Java System Application Server 8.2 Administration Guide』を参照してください。
Web モジュールが仮想サーバーのデフォルト Web モジュールである場合、その Web モジュールの再配備または配備取り消しを行おうとすると、次のエラーが発生します。
Trying to undeploy application from domain failed; Virtual Servers [server] have <WEB-MODULE-NAME\> as default web module. Please remove the default web module references first. ; requested operation cannot be completed Virtual Servers [server] have <WEB-MODULE-NAME\> as default web module. Please remove the default web module references first.
この時点で domain.xml がエラー状態になっています。管理コンソールは、配備された Web アプリケーションの一覧を表示できない可能性があります。ドメインを停止したあとに再起動したとしても、この状況は変わりません。
デフォルト Web モジュールを変更します。
管理コンソールで仮想サーバーのページを表示し、デフォルト Web モジュールを空にするか、別の Web モジュールに変更します。
CLI で、domain をターゲットとして指定し Web モジュールの配備を取り消します。
# asadmin undeploy --target domain <WEB-MODULE-NAME\> |
これで管理コンソールの表示が正しくなります。必要に応じて Web モジュールを再度配備できます。
AMX API を使用して PE にアプリケーションを配備し、そのアプリケーションが参照されないと、Application Server GUI はアプリケーションの表示中にエラーをスローします。AMX では、アプリケーションの参照を明示的に処理する必要があります。たとえば、アプリケーションの配備時に DeployedItemRefConfig を明示的に作成する必要があります。配備プロセスを簡単にするには、PE に参照が存在すると見なしますが、これは Application Server GUI での問題を引き起こします。
リソースまたはアプリケーションを作成したら、それらへの参照を必ず作成します。
Application Server のドメインまたはサーバーが、関連付けられた設定の java-config 要素の java-home 属性によってポイントされる JDK を使用しません。
該当のサーバーインストール内のすべてのドメインに対して Application Server プロセスが使用する JDK は、appserver-installation-dir /config/asenv.conf ファイルによって決まります。使用される JDK は、このファイル内のプロパティー AS_JAVA によって決まります。これはインストール時に設定されます。インストール後に別の JDK を Application Server プロセスが使用するようにするには、別の JDK をポイントするようにこの値を編集します。この変更によって、このインストール内のすべてのドメインが影響を受けることに注意してください。
asenv.conf ファイルを手動で変更する場合は有効性がチェックされないため、変更時に注意が必要です。AS_JAVA の値を修正する場合は、製品のマニュアルで JDK のバージョンの最低限の要件を確認してください。
現在の JDK コードでは、/dev/poll セレクタはセレクタが使用するために 8192 pollfd エントリの配列を割り当てます。これが nofiles ulimit を超過するため、「引数が正しくありません」のエラーで失敗します。さらに、selector.select() が壊れているため、起動時に MQ に接続する Application Server のソケットサービスが IOException で失敗します。
pollfd ファイルの記述子制限を増やします。これには次の 2 つの方法があります。
ルートユーザーとしてシェル上で ulimit -n 8193 を実行します。
ファイル記述子の数値の強い制限値を 8193 以上に増やします。
ulimit -n -H コマンドで強い制限値を確認します。
8193 よりも小さい場合は、/etc/system を編集して、set rlim_fd_max=8193 コマンドを追加します。
マシンをリブートします。
ドメインのマスターパスワードにパーセント文字 (%) が含まれるときにドメインが起動しません。
ドメインのマスターパスワードにパーセント文字 (%) を含めないようにしてください。これは、新しいドメインを作成するとき、および既存のドメインのマスターパスワードを変更するときに適用されます。
次の内容を JVM プロキシ設定に追加すると、サーバーが起動しません。
<jvm—options>-Dhttp.proxyHost=webcache.east.sun.com</jvm—options> <jvm—options> -Dhttp.proxyPort=8080</jvm—options> <jvm—options>-Dhttp.nonProxyHosts="mssp.ctu.gov|*.ctu.gov|localhost" </jvm—options> |
* 文字を挿入すると、No Class Def Found エラーが発生します (スレッド main java.lang.NoClassDefFoundError: com/sun/enterprise/security/store/IdentityManager の例外)。| 文字を挿入すると、サーバーの起動を待機する起動スクリプトがタイムアウトします。
この機能は、ファイアウォールの内側に存在し、外部サーバーと内部サーバーのどちらにもアクセスすることが必要な Application Server の配備 (およびポータル配備) をサポートするために重要です。この例として、Portal Server URL Scraper があります。これらの設定は、URL Scraper が外部ソースからコンテンツを取得するために必要です。
install-dir/config/asenv.conf ファイルを編集し、AS_NATIVE_LAUNCHER="true" の行を AS_NATIVE_LAUNCHER="false" に変更します。
この節では、アプリケーションクライアントに関する既知の問題とその解決方法を示します。
クライアント JAR (この場合は reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。
現時点ではありません。
CGI-bin や SHTML などの動的コンテンツ技術のサポートは終了しました。
代わりに JSP または Web サービスの技術を使用してください。
この節では、データベースドライバに関する既知の問題とその解決方法を示します。
別のアプリケーションサーバーからアプリケーションをポート設定した場合、接続がタイムアウトしたあとに物理接続が正しく閉じられません。この問題は、クライアントライブラリ (Type II) ドライバの DB2 8.1.x バージョンで、同じ DB2 7.1.x Database Server に対して見られます。
SteadyPoolSize と MaxPoolSize を同じ値に設定し、Idle Connection タイムアウトを 0 (ゼロ) に設定します。これにより、アイドル状態の接続のタイムアウトが無効になり、ユーザーはすべてのセットの接続を利用できます。
この節では、Deploytool に関する既知の問題とその解決方法を示します。
sun-application-client.xml
sun-ejb-jar.xml
sun-web.xml
「メッセージ送信先」タブの「JNDI 名」に指定された JMS 送信先リソースが Sun 記述子に保存されていない可能性があります。送信先名 (たとえば、create-jmsdest で作成された物理送信先である PhysicalQueue) を指定して Enter キーを押すと、「表示名」の下に「送信先名」が表示され、クライアント名または Bean 名が「プロデューサ」リストに表示されます。「Sun 固有の JNDI 名」テキストフィールドに「jms/Queue」と入力して Enter キーを押すと、アプリケーションはタイトルバーで「(変更されています)」とは表示されず、エラーが ~/.deploytool/logfile に書き込まれます。アプリケーションを保存し、「メッセージ送信先」タブに戻ると、「JNDI 名」フィールドは再度空白になります。「ツール」、「記述子ビューア」、「Application Server 記述子」の順に選択して Sun 記述子を表示すると、<jndi-name\> 要素内の <message-destination\> 要素は作成されていません。
問題は、Deploytool セッション中に「メッセージ送信先の JNDI 名」に値を初めて入力すると、Sun 記述子内では値が正しく見えますが、org.netbeans.modules.schema2beans.BeanProp.setElement() によって IllegalArgumentException がスローされることです。その後、同じアプリケーションまたは別のアプリケーションで「メッセージ送信先の JNDI 名」を変更または追加しても、Sun 記述子に保存されません。
既存のメッセージ送信先の JNDI 名を編集するには、次の手順に従います。
「JNDI 名」テキストフィールドを空白のままにして Enter キーを押すことで、既存の JNDI 名を削除します。
新しい JNDI 名を入力し、Enter キーを押します。
「ツール」、「記述子ビューア」、「Application Server 記述子」の順にクリックして、Sun 記述子を確認します。
「ファイル」、「保存」の順にクリックして、アプリケーションを保存します。
JNDI 名が Sun 記述子に保存されていない場合は、次の手順に従います。
Deploytool を再起動します。
「メッセージ送信先」タブでメッセージ送信先を選択するか、新しいメッセージ送信先を追加します。
「Sun 固有の JNDI 名」テキストフィールドにメッセージ送信先の JNDI 名を入力し、Enter キーを押します。
「ツール」、「記述子ビューア」、「Application Server 記述子」の順にクリックして、Sun 記述子を確認します。
「ファイル」、「保存」の順にクリックして、アプリケーションを保存します。
Deploytool のセッション中に初めて「JNDI 名」テキストフィールドに値を入力する場合を除き、「メッセージ送信先」タブで「Sun 固有の JNDI 名」に値を入力する必要が生じるたびにこの手順を繰り返します。
Deploytool で Enterprise Bean を作成し、Bean ノードの「トランザクション」タブまたは「セキュリティー」タブを表示すると、「Local Home」および「Remote Home」のラベルが「Local Installation Directory」および「Remote Installation Directory」と誤って翻訳されています。
この節では、マニュアルに関する既知の問題とその解決方法を示します。
AMX (Application Server Management eXtenstions) に関する記述に、Application Server Platform Edition 8.2 で使用できない監視機能が含まれます。具体的には、Platform Edition で監視できないコンポーネントは次のとおりです。
Production Web Container (PWC):
PWC HTTP サービス
PWC 接続キュー
PWC スレッドプール
PWC DNS
PWC キープアライブ
PWC ファイルキャッシュ
PWC 仮想サーバー
PWC 要求
Web モジュール
SessionSize
ContainerLatency
SessionPersistTime
CachedSessionsCurrent
PassivatedSessionsCurrent
StatefulSessionStore
CheckpointCount
CheckpointSuccessCount
CheckpointErrorCount
CheckpointedBeanSize
CheckpointTime
すべて不要です。これらの統計情報は、Platform Edition に関係しません。
『Sun Java System Application Server Platform Edition 8.2 Developer’s Guide』の『Sun Java System Application Server Platform Edition 8.2 Developer’s Guide』の第 2 章「Securing Applications」の『Sun Java System Application Server Platform Edition 8.2 Developer’s Guide』の「Realm Configuration」の節で、誤って com.sun.appserv.AbstractLoginModule と記述されています。ただし現在では、このクラスは com.sun.appserv.AppservLoginModule という名前が付けられています。
com.sun.appserv.AbstractLoginModule の代わりに、com.sun.appserv.AppservLoginModule としてください。
--passwordfile には短縮型のオプションはありません。現在、マニュアルページに -W --passwordfile という記載があります。これは誤りです。
Application Server 8.2 Platform Edition で —W オプションを使用して --passwordfile を使用しないでください。この短縮型オプションは将来の Application Server リリースで追加される予定です。
NumConnAcquired 統計値と NumConnReleased 統計値の getter メソッドが ConnectorConnectionPoolStats および AltJDBCConnectionPoolStats から欠けている。これらの getter メソッドは、将来のリリースで getNumConnAcquired() および getNumConnReleased() として追加される予定です。
EJBCacheStats 内でgetPassivationSuccesses()、getExpiredSessionsRemoved() 、getPassivationErrors()、getPassivations() の各メソッドを呼び出すと例外がスローされる。これは将来のリリースで解決される予定です。
サーバーを起動したあと、すべての AMX MBeans が登録されて利用できるようになるまでに数秒を要することがある。将来のリリースでは、AMX MBeans が完全にロードされたことを確認できるようになる予定です。
定数 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR のスペルに誤りがある (「NNN」)。これは将来のリリースで訂正される予定です。
この節では、インストールおよびアンインストールに関する既知の問題とその解決方法を示します。
この問題は Solaris x 86 プラットフォームで報告されることがありますが、Solaris SPARC および Linux プラットフォームでも発生する可能性があります。
インストーラまたはアンインストーラが最初に表示する画面で、すべてのテキストと「ヘルプ」および「取消し」の各ボタンは正しく表示されますが、次の画面に移動するための「次へ」ボタンが表示されません。ボタンが見えなくてもその部分は有効で、クリックすると次の画面に正しく移動します。問題の原因は、J2SE GUI の再表示が途切れることにあります。
1 つの回避策として、「ヘルプ」ボタンの左側の「次へ」ボタンが表示されるはずの部分をクリックする方法があります。もう 1 つの回避策としては、画面のサイズをわずかに変えるか、一度最小表示にしてから再表示することによって、画面を強制的に再描画する方法があります。再描画後は「次へ」ボタンが見えるようになります。
この問題は、いくつかの Linux システム上で発生していました。これは Java Desktop System 2 でもっとも一般的に見られますが、RedHat ディストリビューションでも見られます。
インストーラの最後の画面で「完了」ボタンをクリックすると、インストーラは製品の「バージョン情報」ページまたは製品登録ページを表示するブラウザウィンドウの起動に失敗し、コマンドプロンプトに戻ることなくハングアップしたままになります。
インストーラを起動した端末ウィンドウで Ctrl+C を押してインストーラを終了します。そのあとで、製品の「バージョン情報」ページまたは登録ページを表示するブラウザウィンドウが起動することがあります。ブラウザウィンドウが現れない場合には、ブラウザを起動してから次の URL を入力して「バージョン情報」ページを確認してください。
file://install_dir/docs/about.html
製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。
Linux インストーラを起動する setup 実行可能ファイルがハングすることがあります。J2SE の場所を解決してインストールウィザードを起動せずに、ラッパーがハングし、次のメッセージを返します。
Chcking available disk space.... Checking Java(TM) 2 Runtime Environment.... Extracting Java(TM) 2 Runtime Environment.... Deleting temporary files.....
この問題は Linux の一部のバージョンで見られ、特に JAVA_HOME 変数が存在する場合など環境設定に依存するようです。
この問題を回避するには、次の手順に従います。
シェルに応じて unset または unsetenv を実行して、JAVA_HOME 変数の設定を解除します。
-javahome オプションを使用して setup を実行して、インストーラが使用する JAVA_HOME を指定します。
この節では、ライフサイクル管理に関する既知の問題とその解決方法を示します。
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery- Interval (7,000) should be greater than or equal to Minimum-delivery- interval-in-millis (9,000)] [exec] CLI137 Command set failed.
minimum-delivery-interval は、同一の周期タイマーの最小発生間隔。
redelivery-interval-in-mills は、失敗した ejbTimeout のあとに再発生を試みるまでタイマーサービスが待機する時間。
これは、再発生間隔のプロパティーを最小発生間隔のプロパティーと関連付けるロジックが間違っていて、GUI または CLI を使用して再発生間隔よりも最小発生間隔が大きくなるような値を設定できないという問題です。
minimum-delivery-interval-in-millis を、ejb-timer-service プロパティーの redelivery-interval-in-millis 以上の値に設定する必要があります。問題は、redelivery-interval-in-millis の値が minimum-delivery-interval-in-millis の値よりも大きいことを検証するための Application Server の処理にエラーがあることです。
次のように、これらプロパティーのデフォルト値を使用します。
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000
これらデフォルト以外の値を指定するとエラーが発生します。
この節では、ログに関する既知の問題とその解決方法を示します。
JVM の java.security.debug オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、domain.xml で次の設定を行うと、この問題が発生します。
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
現時点ではありません。このフラグは設定しないでください。
この節では、Application Server 8.2 製品に付属するサンプルコードに関する既知の問題とその解決方法を示します。
<install_dir>/samples/webservices/jaxrpc/apps/managementws でベリファイアを実行すると、次の警告が表示されます。
[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \ managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path manifest attribute, but it is not found in ear file [exec] Dec 14, 2005 11:14:30 AM Archive getBundledArchives [exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \ managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path manifest attribute, but it is not found in ear file |
Castor jar は Application Server 8.2 リリースで更新されたため、古い castor-0.9.3.9-xml.jar への参照をすべて新しい castor-0.9.9.1.jar をポイントするように変更してください。特に、MANIFEST.MF ファイル内の参照を、古い castor-0.9.3.9-xml.jar ではなく、castor-0.9.9.1.jar を使用するように変更する必要があります。
次の古い Castor jar への参照を、新しい Castor jar をポイントするように変更してください。
旧:
src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.3.9-xml.jar src/conf/MANIFEST.MF:Name: library/castor-0.9.3.9-xml.jar managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \ library/castor-0.9.3.9-xml.jar |
新:
src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.9.1.jar src/conf/MANIFEST.MF:Name: library/castor-0.9.9.1.jar managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \ library/castor-0.9.9.1.jar |
次に、build.xml ファイルをクリーンアップして、Castor .jar が配備中に install_dir /lib にコピーされたり、配備の取り消し中に削除されたりしないようにします。次に新旧の build.xml ファイルの違いを示します。
% cvs diff build.xml Index: build.xml =================================================================== RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \ managementws-standalone-client/ Attic/build.xml,v retrieving revision \ 1.1.2.3 diff -r1.1.2.3 build.xml 80,89d79 < <target name="remove_castor_from_classpath"> < <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/> < </target> < <target name="add_castor_to_classpath"> < <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/> < <copy file="../lib/castor-0.9.9.1.jar" \ todir="${com.sun.aas.installRoot}/lib" /> < </target> < < <target name="setup" depends="add_castor_to_classpath, restart.server"/> < jbenoit/galapago 196 >pwd /net/galapago.east/files/share/8.2ws/samples/samples8x/webservices/jaxrpc \ /apps/managementws/managementws-standalone-client jbenoit/galapago 197 >cd .. jbenoit/galapago 198 >cvs diff build.xml Index: build.xml =================================================================== RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \ Attic/build.xml v retrieving revision 1.1.2.4 diff -r1.1.2.4 build.xml 28,36d27 < <target name="setup"> < <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \ {standalone-client-dir-suffix}" target="setup"/> < </target> < < <target name="unsetup"> < <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \ {standalone-client-dir-suffix}" target="remove_castor_from_classpath"/> < </target> < < 53,54c44,45 < <target name="deploy" depends="select_binary_common, deploy_common, setup" /> < <target name="undeploy" depends="init, undeploy_common, unsetup"/> --- > <target name="deploy" depends="select_binary_common, deploy_common" /> > <target name="undeploy" depends="init, undeploy_common"/>
この節では、セキュリティーに関する既知の問題とその解決方法を示します。
アプリケーションクライアントが、ほかの Web サービスクライアントにユーザー名とパスワードを渡していません。
必要に応じて、次のようにクライアントプログラムにユーザー名とパスワードの組み合わせを明示的に渡します。
((Stub)yourWSPort)._setProperty(Stub.USERNAME_PROPERTY, "yourUsername"); ((Stub)yourWSPort)._setProperty(Stub.PASSWORD_PROPERTY, "yourPassword");
この節では、アップグレードユーティリティーに関する既知の問題とその解決方法を示します。
アップグレードユーティリティーを実行しているときに、install_dir をソースインストールディレクトリとして指定すると、そのアップグレードプロセスは、install_dir /domains ディレクトリの下に作成されたドメインだけをアップグレードします。その他の場所に作成されたドメインはアップグレードされません。
アップグレードプロセスを起動する前に、すべてのドメインディレクトリを、それぞれの場所から install_dir /domains ディレクトリに移動します。
複数のドメインを設定している 8.0 Application Server をアップグレードしたあとに、ドメインを同時に起動できません。これは、JMX コネクタ用に同一のポート番号が設定されているためです。
ポート値を変更します。
次のエントリについて、install dir /domains/domain1/config/domain.xml ファイルをチェックします。
<jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name= "admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" security-enabled="false"/\>" -- and in file <as 8.1 install dir\> /domains/domain1/samples/config/domain.xml, notice it used the same port "8686", so it failed to start domain due to port conflict. |
ポート値を 8686 から 8687 に変更し、domain1 を再起動します。
この問題は複数の Linux システムで発生しています。Java Desktop System 2 でもっとも一般的ですが、RedHat ディストリビューションでも発生しています。
インストーラの最後の画面で「アップグレードツールの起動」ボタンをクリックすると、インストーラはアップグレード処理を完了するためのアップグレードツールの起動に失敗し、コマンドプロンプトに戻ることなくハングアップしたままになります。
この問題は、アップグレードを実行するのにコマンド行インストールモードを使用した場合には発生しません。
GUI モードで代替アップグレードを実行してこの問題が発生した場合には、インストーラを起動した端末ウィンドウで Ctrl+C を押すことにより、そのインストーラを終了します。
その端末ウィンドウから次のコマンドを使用してアップグレードツールを起動します。
install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser--adminpassword adminpassword --masterpassword changeit |
adminuser および adminpassword は、アップグレード中のインストールで使用されている値に一致する必要があります。
アップグレードツールがアップグレードプロセスを完了したあとは、ブラウザを起動して次の URL を入力することにより、「バージョン情報」ページを参照できます。
file://install_dir/docs/about.html
製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。
以前のバージョンの Application Server から複数言語版の Application Server 8.2 へアップグレードすると、「結果」パネルに不要な文字が表示されることがあります。さらに、/opt/SUNWappserver/domains/upgrade.log ファイルに不要な文字が表示される場合もあります。
現時点ではありません。この問題は、将来の Application Server リリースで解決される予定です。
この節では、Web コンテナに関する既知の問題とその解決方法を示します。
Windows にアプリケーションを配備するときに JSP のプリコンパイルを要求すると、それ以降、そのアプリケーションの配備取り消しや、そのアプリケーション (または同一モジュール ID を持つ任意のアプリケーション) の再配備を試みても、予期したとおりに動作しません。この問題は、JSP のプリコンパイル処理でアプリケーションの JAR ファイルが開かれたまま閉じられないため、Windows がこれらのファイルを配備取り消しで削除することや、これらのファイルを再配備で上書きすることを許可しないことにあります。
配備取り消しは、Application Server からアプリケーションが論理的に削除されるという点では成功します。また、asadmin ユーティリティーからエラーメッセージは返されませんが、アプリケーションのディレクトリとロックされた jar ファイルはサーバー上に残っています。サーバーのログファイルには、ファイルと アプリケーションのディレクトリの削除に失敗した旨のメッセージが出力されます。
配備取り消し後のアプリケーションの再配備が失敗するのは、既存のファイルとディレクトリをサーバーが削除しようとして失敗するからです。これは、最初に配備されたアプリケーションと同じモジュール ID を持つアプリケーションを配備しようとしたときにも発生します。アプリケーションのファイルを保持するディレクトリの名前を、サーバーはモジュール ID から決定するからです。
同様の理由から、配備取り消しをせずにアプリケーションを再配備しようとすると失敗します。
アプリケーションを再配備しようとすると、または、配備取り消しを行なってから配備しようとすると、asadmin ユーティリティーは次のようなエラーを返します。
An exception occurred while running the command. The exception message is: CLI171 Command deploy failed : Deploying application in domain failed; Cannot deploy. Module directory is locked and can\qt be deleted
アプリケーションの配備時に --precompilejsps=false を指定すると (デフォルト設定)、この問題は発生しません。そのアプリケーションを最初に使用するときに JSP コンパイルが起動されるため、最初の要求に対する応答時間は、その後の要求に比べて長くなります。
また、プリコンパイルを行う場合には、そのアプリケーションを配備取り消しまたは再配備する前に、サーバーを終了して再起動する必要があります。シャットダウンすると、ロックされている JAR ファイルが解放されるため、再起動後の配備取り消しや再配備が成功します。
web.xml のオプションの load-on-startup サーブレット要素は、関連付けられているサーブレットを宣言する Web アプリケーションの起動の一環として、そのサーブレットをロードおよび初期化すべきことを示します。
この要素のオプションの内容は、Web アプリケーションのその他のサーブレットとの関係で、そのサーブレットをロードおよび初期化する順序を示す整数です。空の <load-on-startup\> は、そのサーブレットを含む Web アプリケーションの起動時にそのサーブレットがロードおよび初期化される場合、その順序は意味を持たないことを表します。
web.xml の Servlet 2.4 スキーマでは、空の <load-on-startup\> はサポートされなくなりました。つまり、サーブレット 2.4 ベースの web.xml を使用する場合は整数値を指定する必要があります。<load-on-startup/\> の場合と同様に、空の <load-on-startup\> を指定すると、web.xml が web.xml のサーブレット 2.4 スキーマに対する妥当性検証に失敗するため、Web アプリケーションの配備も失敗します。
下位互換性の問題もあります。空の <load-on-startup> は、Servlet 2.3 ベースの web.xml では有効です。
Servlet 2.4 ベースの web.xml を使用する場合は、<load-on-startup\>0</load-on-startup\> を指定して、サーブレットの読み込み順序が問題にならないことを示します。
JSP ページにアクセスしてもコンパイルに失敗し、サーバーログには「Unable to execute command」というエラーメッセージと次のスタックトレースが記録されます。
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec (Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.launch (Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute (Execute.java:427) at org.apache.tools.ant.taskdefs.compilers. DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter. java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal. execute(JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac. compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute (Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass (Compiler.java:396)
JSP のコンパイルスイッチを fork から false に設定します。
これは、次のいずれかの方法で行えます。
グローバルに行うには、次のように、${S1AS_HOME}/domains/domain1/config/default-web.xml 内の JspServlet の fork init パラメータを false に設定します。
<servlet\> <servlet-name\>jsp</servlet-name\> <servlet-class\>org.apache. jasper.servlet.JspServlet</servlet-class\> .... <init-param\> <param-name\> fork</param-name\> <param-value\>false</param-value\> </init-param\> .... </servlet\>
Web アプリケーションごとに、sun-web.xml の JSP 設定プロパティー fork を false に設定します。次のようにします。
<sun-web-app\> <jsp-config\> <property name="fork" value="false" /\> </jsp-config\> </sun-web-app\>
これらのいずれかを設定することにより、ant が javac コンパイルのための新規プロセスを生成することが防止されます。
Application Server PE のデフォルト設定では、マルチ CPU のマシンで最適に動作しません。その代わりに起動が高速化されていますが、Web アプリケーションのパフォーマンスに悪影響を与える可能性があります。
Application Server の設定を変更して 次の JVM オプションを使用します。
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false
仕様に準拠しない Fast Infoset でエンコードされた SOAP メッセージが JAX-RPC サービスに送信されると、サービスは適切にエラーを返します。また、そのあとに仕様に準拠する Fast Infoset でエンコードされた SOAP メッセージが同じサービスまたは同じ JAX-RPC ランタイムを使用するように配備されたサービスに送信されると、不正に障害が発生する可能性があります。
次の回避策があります。
クライアントで Fast Infoset を無効にして、XML でエンコードされた SOAP メッセージだけが送信されるようにします。
サービスを配備するコンテナを再起動して、仕様に準拠する Fast Infoset でエンコードされた SOAP メッセージを送信できるようにします。