Sun Java Enterprise System 7 リリースノート

Previous: 第 2 章 Java ES 7 の製品の相互運用性

第 3 章既知の問題点と制限事項

次の節では、Java ES 7 に関して次の種類の問題を説明します。

Java ES 7 製品をインストールするときの特殊な状況に関連した問題
以前のバージョンの Java ES から Java ES 7 製品にアップグレードするときの特殊な状況に関連した問題
Java ES 7 の複数製品の相互運用性に関連した問題
Java ES 7 製品に関する優先度の高い問題

すばやく参照できるように、この章で説明する問題のリストを示します。

これらの多くの問題に関する詳細および更新は、http://sunsolve.sun.com、http://bugs.sun.com、または http://java.net で検索できます。

(4756/4809) Portal Server 7.1u2 の同一ノード上の共存問題

説明

Access Manager 7.1.1 から OpenSSO 8.0 へ移行したあと、Portal Server 7.1u2 は Portal Server と Access Manager を別のノードに配備すれば正しく機能しますが、同じノード上に配備すると機能しなくなります。Portal Server を正しく初期化できず、次のエラーがサーバーログに表示されます。

[#|2009-03-23T19:06:37.004+0100|SEVERE|sun-appserver2.1|javax.enterprise.system.
container.web|_ThreadID=10;_ThreadName=main;_RequestID=00e6500a-e66c-42f4-9f06-6
afdace1a2d8;|WebModule[/surveys]PWC1275: Exception sending context initialized e
vent to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.NoClassDefFoundError: com/iplanet/sso/SSOException

この障害が発生する原因は、OpenSSO Enterprise と Access Manager の AM SDK コンポーネントが同じ Web コンテナ (Application Server/GlassFish) 内に共存できないこと、さらに Portal Server が AM SDK コンポーネントを必要としていることにあります。

このバグの詳細は、次の URL を参照してください。

4756
4809

解決法

OpenSSO は、パッケージベースの AM SDK をサポートしません。AM SDK ベースのインストールには、直接アップグレードできるパスはありません。推奨される回避方法は、次のとおりです。
1. Application Server 8.2 で実行されている Portal Server/AM SDK をそのままにします。
2. 新しい GlassFish Enterprise Server v2.1 をインストールし、Access Manager 7.1 と同じ Directory Server Enterprise Edition を指し示すこの GlassFish インスタンスに /amserver で OpenSSO を配備します。
3. Portal Server/AM SDK を、別のポート上にある OpenSSO に向けて構成し直します。

(5509) OpenSSO 8.0U1P1: `LifecycleException: java.lang.StackOverflowError` で、再配備できない

説明

この問題は、Access Manager 7.1 から 8.0U1P1 へ行うべき一連のアップグレード手順のあとで見受けられます。これについては、関連ドキュメント『Sun OpenSSO Enterprise 8.0 Upgrade Guide』の「Upgrading to OpenSSO Enterprise 8.0」に説明されています。
1. AM7.1 の配備を取り消します。
2. ssopre80upgrade スクリプトを実行します。
3. OpenSSO 8.0 Enterprise を配備します。
4. 既存のデータストア (この場合は DSEE 6.3.1) に対する配備を構成します。
5. ssoupgrade スクリプトを実行します。
6. OpenSSO (optional) が動作していることを確認します。
7. ssopatch ツールで、8.0U1P1 にステージング領域を用意します。
8. このステージング領域から、WAR ファイルを用意します。
新しい amserver.war を配備しようとすると失敗し、アプリケーションの起動中に無限ループがあるように表示される。

このバグの詳細は、5509 のレポートを参照してください。
解決法

この問題は、最新の OpenSSO Enterprise patch で解決されています。アップグレードするには、OpenSSO Enterprise version 8.0 Update 1 Patch 4 以降を使用してください。

(5571) OpenSSO 8.0 Upgrade: `ssoupgrade` のあと、Web Server にエラーがスローされる

説明

Solaris 9u7 SPARC 上で Java ES 4 パッケージベース (DS5.2、WS6.1、AM7.0、PS6.3.1) を Java ES 7 へアップグレードすると、ssoupgrade を実行してから再起動後にエラーがスローされます。

このバグの詳細は、5571 のレポートを参照してください。
解決法

この問題は、最新の OpenSSO Enterprise patch で解決されています。アップグレードするには、OpenSSO Enterprise version 8.0 Update 1 Patch 4 以降を使用してください。

(5634) GF 2.1 クラスタに Opensso を配備すると、`ssoadm get-svrcfg-xml` が動作しない

説明

Web Space Server OpenSSO Add-On は、GlassFish LoadBalancer の先にある GlassFish クラスタノード上の OpenSSO の構成を取得することができません。そのため、OpenSSO Add-On は失敗します。

このバグの詳細は、5634 のレポートを参照してください。
解決法

GlassFish Cluster には OpenSSO を配備せず、代わりに OpenSSO Session のフェイルオーバー機能を使用します。

(5696) Java ES 7: パッチ 141655-02 によるパッチ OpenSSO 8.0 が失敗する

説明

この問題は、『Sun OpenSSO Enterprise 8.0 Upgrade Guide』の「Upgrading to OpenSSO Enterprise 8.0」の製品ドキュメントに説明されている、Access Manager 7.1 から 8.0U1P2 へアップグレードする一連の手順を実行したあとに起こります。

このバグの詳細は、5696 のレポートを参照してください。
解決法

次を確認します。
1. 「updateschema スクリプトの実行」にある 8.0U1 パッチインストール手順の説明どおりに、ssoadm ツールを使用します。
2. updateschema.sh を実行する前に、-D"com.iplanet.am.naming.map.site.to.server=<lb-url>=<server-url>" を、関連するssoadm (ssoadm.bat ) スクリプトに追加してください。

(20404) Directory Server と Identity Manager: Identity Server でユーザーアカウント ID を変更した場合、LDAP グループメンバーシップが維持されない

説明

Identity Manager LDAP リソースアダプタを介して Directory Server 6.3.1 LDAP ストアが Identity Manager 8.0 で管理可能なときに、Identity Manager でユーザーアカウント ID を変更した場合、そのユーザーの LDAP グループメンバーシップがメンテナンスされません。このことは、Identity Manager の accountId 属性が LDAP cn 属性と uid 属性の両方にマップされている場合でも当てはまります。
解決法

ありません。

(6358422/2183559) Appserver 7.1/8.1 EE: Web サーバー LB のプロキシプラグインは、キープアライブ接続を正しくサポートすべきである

説明

Sun Java System Application Server 7.1/8.1 の負荷分散のプロキシプラグインを Sun Web Server 7 で使用すると、極度の負荷で要求がドロップされることがあります。ログに表示されるエラーメッセージは、次のとおりです。
RNTM3003: No server to service
解決法

解決策はありませんが、2 種類の回避策があります。
1. Web Server 7 のタイムアウト設定を無効にします。
  web-server-install-dir/bin/wadm set-keep-alive-prop \ --user=admin --config=server-name timeout=-1
2. Web Server を再起動します。

(6762401) Web Space Server Portal が Policy Agent (2.2、3.0) を使用したリバースプロキシ機能で正しく描画されない

説明

条件によっては、HTTP 応答が Web サーバーのリバースプロキシ機能を介して正しく転送されないので、結果として Web ブラウザ内の Web ページが正しく描画されません。この問題は、Web Space Server 上で SSO Policy Agent とリバースプロキシの両方を同時に実行すると発生します。
解決法

リバースプロキシを介したアクセスはサポートされていません。Secure Web Access (SWA) Add-On Secure を使用して、OpenSSO で Web Space Server にアクセスする方式をお勧めします。

(6808492) GF 2.1 CLI の配備を取り消そうとすると失敗し、それ以降のすべての CLI コマンドが失敗する

説明

Sun Java™ Enterprise System 7 の配備を取り消そうとすると失敗し、「Invalid user or password」というメッセージが表示され、それ以降は同じエラーメッセージが表示されて、どのコマンドを発行しても失敗してしまいます。同時に、GUI からログインできなくなり、CLI だけの認証問題にとどまらなくなります。ドメインを再起動するとこの問題は解消されますが、amserver の配備が取り消されないため、もう一度配備を取り消そうとすると、この問題が再び発生します。GUI から配備を取り消そうとした場合は、同じ認証失敗が起こりますが、少なくとも Web アプリケーションの配備が取り消されます。
解決法

ありません。少なくとも CLI 機能と GUI 機能だけを元に戻すには、GlassFish ドメインを再起動してください。

(6818829) JES6: GF2.1: GF 管理ページからログアウトできない

説明

GlassFish Enterprise Server の管理ページの「ログアウト」ボタンをクリックしたあと、空の確定警告が表示されます。「OK」をクリックすると、コンソールページが再度読み込まれますが、ログアウトされません。

この問題は、Access Manager 7.x と GlassFish 2.1/2.1.1 に影響しますが、最新の Access Manager パッチで解決されました。この問題は、Application Server 8.x を GlassFish 2.x に更新したときに、最新の Access Manager パッチを適用しなかったり、OpenSSO Enterprise Edition にアップグレードしなかったりした場合に起こります。

解決法

GlassFish Enterprise Server の server.policy ファイルで、次の行を変更します。

permissiion java.security.AllPermission "MonitoringAuth.*";

permission java.security.AllPermission "MonitoringPolicy.*";

次のように変更します。

permission javax.management.MBeanServerPermission "*";

permission javax.management.MBeanPermission "*", "*";

permission javax.management.MBeanTrustPermission "*";

permission java.io.FilePermission "//var/opt/SUNWmfwk/logs/*", "delete,write";

最後の行のパスが 2 つのスラッシュ (//) で始まっていることに注意してください。最初のスラッシュは、SUNWmfwk-rt のインストールディレクトリを示します。デフォルトのインストールディレクトリ (Solaris の場合 /opt、Linux の場合 /opt/sun) は単一スラッシュで示されます。

(6819380) GlassFish Enterprise Server と Identity Manager: GlassFish Enterprise Server へのアップグレード中に、Identity Manager の `idm.war` ファイルを再配備できない

説明

Application Server 8.2 からアップグレードする GlassFish Enterprise Server に付属のアップグレードユーティリティーを使用した場合は、アップグレードログに idm.war ファイルが配備されないという記録が残ります。
解決法

アップグレードユーティリティーで修正し配備を試行したファイルでなく、元の idm.war ファイルを配備してください。Identity Manager をデフォルト設定でインストールした場合、元の war ファイルは /opt/idm.war となります。

(6834364) SUN LoadBalancer `lbplugin` がインストールされている場合、シャットダウン時に Web Server 7 がコアダンプを生成してしまう

説明

lbplugin がインストールされた状態で Web Server 7.0 をシャットダウンすると、コアファイルが生成されます。コアファイルには、次のようなものが記載されています。

current thread: t@1
=>[1] __lwp_kill(0x0, 0x6, 0xfd5f3700, 0xfe822a00, 0xff36f338, 0x0), at 0xfd5c5bf0
[2] raise(0x6, 0x0, 0x20f04, 0xff34ba3c, 0xff36a000, 0xff36abdc), at 0xfd564bf4
[3] umem_do_abort(0x6, 0xffbff018, 0x6, 0x20e40, 0xff356ad8, 0x0), at 0xff349188
[4] umem_err_recoverable(0xff357b54, 0xa, 0x20d38, 0xfe8ae5d8, 0xff36d0e8, \
    0xff357b5f), at 0xff34932c
[5] process_free(0x282468, 0x1, 0x0, 0x3e3a1000, 0x1ec08, 0xfe8ae3fc), \
    at 0xff34b504
[6] INTdaemon_dorestart(0x1, 0xff272ffd, 0xff2abc04, 0x862d58, 0xfcbd40e8, \
    0xff2a2c00), at 0xff0ffb84
[7] WebServer::Run(0x1, 0x0, 0x6, 0x88108, 0x3d, 0xff272ec9), at 0xff1a5d5c
[8] main(0x9, 0xffbff47c, 0xffbff4a4, 0x21400, 0x0, 0xfd035000), at 0x10fd4

この問題は、Web Server 7.x 上で実行している Application Server 8.1、8.2、9.x のすべてで起こります。原因は、エントリの重複です。

Init fn="load-modules" shlib="libj2eeplugin.so" shlib_flags="(global|now)"
Init fn="init-passthrough"
##END LB Plugin Parameters
Init fn="load-modules" shlib="libj2eeplugin.so" shlib_flags="(global|now)"

解決法

Web Server の magnus.conf ファイルにある libj2eeplugin.so への最初の方の重複参照を削除してから、Web Server を再起動します。

(6851521) GF2.1.1: GF アップグレードスクリプトが、PS または IM、あるいはその両方を配備できない

説明

Sun GlassFish Enterprise Server 2.1.1 (Build 17 sges_ee-2_1_1-fcs-bin-b17-solaris-i586-03_jun_2009.bin ) アップグレードツールは、Portal Server 6.3.1 (JES4) アプリケーションを AS 8.1_02 (JES4) から移行できません。

この問題は、Application Server 8.1 から GlassFish へ更新するときに、Portal server 6.3.1 または Instant Messaging、あるいはその両方もインストールされていると、Java ES 4 から Java ES 7 へのアップグレードプロセスに影響します。この問題は、GlassFish 2.x へのアップグレード時に、ほかの古いアプリケーションにも影響することがあります。

この問題は、GlassFish 2.x アップグレードツールの設計不備によるもので、アップグレードプロセス中に、分解したアプリケーションビットからアーカイブが再作成されるために発生します。その結果、アーカイブが再作成されると、jar 署名が無効になります。
解決法

ありません。GlassFish を更新する前に古いアプリケーションを更新しておくか、またはインストールをアップグレードせずに新しい GlassFish のインストールを実行したうえで、古いアプリケーションを GlassFish に手動で再配備してください。

(6881146) GlassFish インストーラ (LB プラグインインストール) が、有効な Web Server インスタンスディレクトリを認識しない

説明

GlassFish v2.1 ファイルベースバージョンの使用時に、GlasFish インストーラで Load Balancer Plugin をインストールしようとすると、インストーラが Web Server インスタンスを受け入れず、<Web-Server のインストール先ディレクトリ> /https-<ホスト名> とは別の場所に作成されます。不正なディレクトリエラーにより、インストールが中断されます。

デフォルトでは、Java ES 5 と Java ES 5 U1 に付属している Web Server 7.0 パッケージが、Sun Java™ Enterprise System 7 内にそのインスタンスを作成します。このインストール先ディレクトリを LoadBalancer プラグインに使用すると、インストールに失敗します。
解決法

インストーラがインスタンスの位置を認識できるよう、Web Server インスタンスのディレクトリから Web Server のインストール先ディレクトリへ、次のようにシンボリックリンクを作成します。
ln -s /var/opt/SUNWwbsvr7/https-<hostname>.<domain> /opt/SUNWwbsvr7/https-<hostname>.<domain>

(6882150) Web Space Server 10.0u6: 10.0 から更新したあと、`com.liferay.util.EncryptorException` がスローされる

説明

Web Space Server 10.0 から 10.0u6 へアップグレードしたあと、次の例外が GlassFish server.log に見られることがあります。

[#|2009-09-15T11:45:19.453+0000|INFO|sun-appserver2.1| \
javax.enterprise.system.stream.out|_ThreadID=23; \
_ThreadName=httpSSLWorkerThread-81-1;|11:45:19,448 \
ERROR [IncludeTag:165] com.liferay.util.EncryptorException: \
com.liferay.util.Encryptor \
Exception: java.security.ProviderException: update() failed
        at com.liferay.util.Encryptor.encryptUnencoded(Encryptor.java:205)
        at com.liferay.util.Encryptor.encrypt(Encryptor.java:174)
        at org.apache.jsp.html.common.themes.top_005fhead_jsp._jspService \
(top_005fhead_jsp.java from :1753)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

解決法

この問題は、最新の Web Space Server 製品のパッチで解決されています。Web Space Server を 10.0 Update 6 Patch 3 以降に更新してください。

(6882644) Java ES 7: GF と WSS が別々のファイルベースの配布からインストールされていると、WSS war ファイルを配備できない

説明

GlassFish と Web Space Server が別々のファイルベース配布からインストールされていると、Web Space Server WAR ファイル (saw-web.war、glassfishregistrationportlet.war 、ruon-web.war、dlmigrationportlet.war、および wsrp-portlet.war) を配備できません。
解決法

管理コンソールを使用するか、ファイルをドメインの autodeploy ディレクトリにコピーして、ファイルを手動で配備します。

(6883003) 2 台構成の GlassFish Cluster に配備した場合、Web アプリケーションが `.wsdl` ファイルを見つけられない

説明

Web Application .war ファイルを 2 台の GlassFish クラスタに配備できますが、Node2 (instance-TWO) にあるアプリケーションの URL にアクセスしようとするとそこに DAS がないため、WSDL ファイルが見つからずに java.io.FileNotFoundException がスローされます。

問題は、DAS が Node2 に存在しないことです。
解決法

domain1 (DAS) にディレクトリ階層を作成してから、Web アプリケーションのファイル検索先にある WSDL ファイルにシンボリックリンクをコピーするか作成します。

(6887791) JCAPS6u2: NetBeans に組み込まれた JSR-168 Portlet が、別のホストに転送できない (WSDL の URL 問題)

説明

JCAPS Web Service を消費する JSR168 Portlet を構築して Web Space Server へ配備すると、WSDL ファイルが見つからないというエラーが出てポートレットを配備できない。この問題は、CalculatorWSService.java にある静的コードが、WAR パッケージ内の相対パスではなく、WSDL のディスク上の絶対パスを指しているために起こります。
解決法

この問題には 2 つの回避方法があります。
1. Web Space Server ホストに目的のディレクトリ階層を作成し、WSDL ファイルをそこにコピーします。
2. 正しい wsdlLocation を指定するため、たとえば次のように Wsimport オプションを手動で調整します (CalculatorPortlet->Web Service References->CalculatorWSService->Edit Web Service Attributes)。
  wsdlLocation=http://jcaps-node1:8080/CalculatorApp/CalculatorWSService?wsdl

(6889609/6889627) Web Server インスタンスが Web Server のインストール先ディレクトリにない場合、Web Server 7.0 NetBeans プラグインが、サーバーを追加しない

説明

追加対象となる Web Server インスタンスが、メインの Web Server インストール先ディレクトリとは別のディレクトリにあるときに、Web Server 7.0 インストールを NetBeans 6.5.1 に追加すると、エラーが発生します。次に例を示します。
- Web サーバーインスタンス:
  /var/opt/SUNWwbsrv7/https-<node> /var/opt/SUNWwbsrv7/admin-server
- Web Server インストールディレクトリ:
  /opt/SUNWwbsrv7
表示されるエラーメッセージは、「Please choose a Valid Sun java System Web Server 7.0 installation. (有効な Sun java System Web Server 7.0 インストールを選択してください)」です。
解決法

ありません。NetBeans 用の Web Server プラグインは、現在のところスタンドアロンのインストールのみで機能しています。インスタンスは管理ライブラリに依存するため、Web Server インストール先ディレクトリと Web Server インスタンスのディレクトリが同一であると見なされます。中でもプラグインは、admin-server、config、server.xml など、複数のディレクトリとファイルがあるかどうかをチェックします。見つからなければ、このプラグインが失敗します。

(6889664) Web Server 7.0 NetBeans プラグインが、JSF Web アプリケーションをサポートしない

説明

Web Server 7.0 を NetBeans Servers タブに追加したあとに Netbeans 6.5.1 と Sun Java System Web Server 7.0 プラグインを使用してから JSF アプリケーションを Web Server に配備しようとすると、javax.faces.FacesException パッケージを解決するエラーが発生します。

問題は、jsf-impl.jar と jsf-api.jar が、プラグインから読み込まれていないことです。NetBeans 用の Web Server プラグインは、これらのクラスの読み込みをサポートしていません。
解決法

「NetBeans Servers」タブでターゲットサーバーに GlassFish v2 を選択し、Web Server ではなく、GlassFish にアプリケーションを構築します。アプリケーションを構築したあと、これを NetBeans から配備せずに、wadm CLI または Web Server 管理コンソールから Web Server へ手動で配備します。

(6891038) LoadBalancer プラグインインストーラが、インストール中に仮想ホストの `obj.conf` ファイルを更新しない

説明

場合によっては、LoadBalancer プラグインが Web Server 7 と、生成された loadbalancer.xml ファイルに正しくインストールされても、LoadBalancer が正しく初期化しないことがあります。

たとえば、次のようなシナリオを考えてみます。
- LoadBalancer プラグインをインストールする前に、ユーザーが Web Server 仮想ホストに指定の構成を実行したとします (Web Server 仮想サーバーログを優先)。この場合、Web Server が新しい obj.conf ファイルを作成し、仮想ホスト名 <WS仮想ホスト名> -obj.conf を付けます。
- LoadBalancer プラグインのインストール時に、このプロセスが自動的に Web Server の各種構成ファイル (server.xml、 magnus.conf、obj.conf) を更新しますが、<WS仮想ホスト名>-obj.conf は更新されません。
この場合、問題は、<WS仮想ホスト名> -obj.conf ファイルが Web Server 起動シーケンスにあるほかの構成ファイルよりも優先されてしまい、必須の lbplugin エントリが見つからず、エラーメッセージが表示されなくても、LoadBalancer が完全に初期化されないことにあります。

解決法

次のエントリを <WS仮想ホスト名> -obj.conf ファイルに手動で追加します。

<Object name="default"> タグの下に、次を 1 行で追加します。

NameTrans fn="name-trans-passthrough" name="lbplugin" \
config-file="/opt/SUNWwbsvr7/https-<ws_config_name>/config/loadbalancer.xml"

ファイルの最後に、次を追加します。

<Object name="lbplugin">
PathCheck fn="deny-existence" path="*/WEB-INF/*"
ObjectType fn="force-type" type="magnus-internal/lbplugin"
Service type="magnus-internal/lbplugin" fn="service-passthrough"
Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
</Object>

<Object ppath="*lbconfigupdate*">
PathCheck fn="get-client-cert" dorequest="1" require="1"
</Object>

<Object ppath="*lbgetmonitordata*">
PathCheck fn="get-client-cert" dorequest="1" require="1"
</Object>

これらの変更が済んだら、LoadBalancer を再起動します。

(6891737) Web Space サーブレットのコンテキスト「 `/`」によって、同じ AS/GF 上へのほかのアプリケーションの配備がすべて防止される

説明

ほかのアプリケーション (OpenSSO 8、Access Manager Server 7 や一部のサンプルアプリケーションなど) がすでにインストールされている GlassFish (v2.1) ドメインに、Web Space Server を配備したあと、これらのアプリケーションにアクセスできなくなることがあります。

問題は、Web Space Server がサーブレットコンテキストのルート (/) を継承するため、すべての Web 参照がポータルインフラストラクチャーを介してリダイクレトされることです。この問題は、Web Space Server のあとに GlassFish へ配備されたアプリケーションには起こりません。つまり、Web Space Server に関するアプリケーションの配備順序が重要になります。
解決法

配備中は、デフォルトのコンテキストルートである「/」を、次のように別のコンテキストルートで指定すれば変更できます。
asadmin deploy -contextroot /foo
これを実行する場合は、portal-ext.properties にある portal.ctx 構成パラメータが一致するように設定しなくてはなりません。詳細は、『Sun GlassFish Web Space Server 10.0 Administration Guide』の「Portal Context」を参照してください。

(6893680) OpenSSO で構成された Web Space: Web Space のパスワード変更が反映されない

説明

Web Space Server が OpenSSO でユーザーを認証するように構成されているとき、Web Space My Account ポートレットで Web Space Server のユーザーパスワードを変更すると、変更したパスワードが OpenSSO サーバーに送信されません。

My Account ポートレットは、Liferay に由来するため、Liferay によるすべての認証機構には同じ問題があります。デフォルトの認証機構以外のものが使用されている場合は、コントロールパネルでパスワードフィールドを変更しても反映されません。これは一般的に外部 SSO ソリューションを使用する際に既に判明している制限事項であり、外部 SSO ソリューションが編集可の場合は、OpenSSO によって制御されるユーザー属性 (ユーザー名やパスワードなど) を編集不可に設定しないか、または SSO サーバーの UI にリダイレクトする必要があります。
解決法

Web Space Server の My Account ポートレットではなく OpenSSO サーバーのインタフェースを使用して、ユーザー属性を変更します。

(6903954) Java ES 7 GF 2.1.1 に配備したスタンドアロンの Web Space Server 10u6 にログインすると、空白ページが表示される

説明

GlassFish 2.1.1 に配備したスタンドアロンの Web Space Server 10 U6 インスタンスにログインできません。ログインすると、空白ページが表示されます。
解決法

この問題は、最新の Web Space Server のパッチで解決されています。Web Space Server をバージョン 10.0 Update 6 Patch 3 以降に更新してください。

Previous: 第 2 章 Java ES 7 の製品の相互運用性

第 3 章 既知の問題点と制限事項