第 3 章 已知問題和限制

本章說明 Sun Java System Application Server Enterprise Edition 8.2 軟體的已知問題和相關解決方法。如果摘要敘述未指明特定的平台，則所有平台都可能出現此問題。這些資訊按以下章節進行分類：

• 管理

• 應用程式用戶端

• 隨附的 Sun JDBC 驅動程式

• 連接器

• 說明文件

• 高可用性

• 安裝

• J2EE Tutorial

• 生命週期管理

• 記錄

• Message Queue

• 監視

• 範例

• 安全性

• 升級公用程式

• Web 容器

管理

本節介紹已知的管理問題以及相關的解決方案。

使用 [安裝時自動配置] 選項的 Application Server 不支援負載平衡程式功能 (6463858)

使用 [安裝時自動配置] 選項的 Application Server 不支援負載平衡程式功能。

解決方法：可以在安裝 Application Server 之後再配置負載平衡程式功能。

您必須在系統上安裝有 Application Server 和 Web Server，才能配置負載平衡程式功能。

若要配置負載平衡程式功能，請遵循下列步驟：

1. 在登錄 HKEY_LOCAL_MACHINE -> Sun Microsystem -> EntSys -> Installer -> Application Server 中，將 IS_LB 的值設定為 true，並將 Cfgr_LB 設定為 false 值。

2. 切換到 setup 目錄。

   cd JavaES-Install-Dir\setup\

3. 執行 ASConfigure.bat 批次檔。

4. 遵循指示並提供適當的值。

   ---

   備註 –

   對於 AS_LB 外掛程式，請鍵入 Sun Java System Web Server [Mandatory]，因為這是 Java ES 5 下唯一支援的外掛程式。

   ---

5. 重新啟動系統。

如果缺少 domain1，package-appclient 程序檔將無法運作 (ID 6171458)

依預設，對於 asenv.conf 指向的 domain1 之AS_ACC_CONFIG 變數，程式內定值位於 JavaES-Install-Dir \lib\lib\package-appclient.xml 中。如果刪除 domain1 並建立新網域，則不會使用新網域名稱更新 AS_ACC_CONFIG 變數，從而造成 package-appclient 程序檔失敗。

解決方案

執行下列動作之一：

• 保留 domain1 的完整，並在周圍建立其他網域。

• 移除 domain1，並將 JavaES-Install-Dir \lib\lib\package-appclient.xml 中 domain1 的程序內定值替代成新網域名稱。每次在沒有 domain1 的情況下建立新網域時，重複執行此步驟。

安裝負載平衡外掛程式會覆寫現有外掛程式 (ID 6172977)

如果您在已安裝負載平衡外掛程式 (例如從 7.1EE) 的 Application Server 中，再安裝其他負載平衡外掛程式，則 8.2EE 外掛程式會無提示取代任何現有的負載平衡程式，即使您已建立用於執行該外掛程式的新伺服器實例亦如此。

依預設，外掛程式檔案安裝在 install_dir /plugins/lbplugin 目錄下，這表示任一 Application Server 安裝只能使用一種版本的外掛程式。請注意，主控台安裝程式將顯示一則訊息，表示正在執行解除安裝，但是很容易錯過此訊息。

解決方案

並非所有使用者都會遇到此類問題。如果您的確遇到此問題，請移除舊的 Application Server 安裝，並執行重新安裝而非升級安裝。

與 Java ES 2 Application Server 7 相比，Java ES 3 Application Server 8.2 中的 asadmin 程序檔有些變更 (ID 6189433、6189436)

與 Application Server 7 及相容版本相比，Application Server 8.2 中的 asadmin 指令已進行了一些變更。例如，Application Server 7 及相容版本中，啟動伺服器實例的指令如下：

asadmin start-instance

在 8.2 版本中，等效指令如下：

asadmin start-domain --user admin domain1

請參考以下文件，以取得有關最新 asadmin 指令語法的完整資訊︰

• 「Sun Java System Application Server Enterprise Edition 8.2 管理指南」

• 「Sun Java System Application Server Enterprise Edition 8.2 Reference Manual」

• 「Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide」

Application Server 中的預設連接埠已變更 (ID 6198555)

從 Java ES 2 Application Server 7 及相容版本升級至 Java ES 5 Application Server 8.2 時，您可能會遭遇到不相容情況或錯誤，這是因為預設連接埠已變更。

無法使用其他名稱復原備份的網域 (ID 6196993)

即使 asadmin restore-domain 指令可提供重新命名網域的選項，仍無法使用原始名稱以外的其他名稱復原網域，因此無法使用 backup-domain 和 restore-domain 指令在同一 Application Server 安裝上執行網域鏡像。重新命名備份的網域看似成功，但嘗試啟動已重新命名的網域卻失敗，因為網域配置中的項目並未變更，並且 startserv 和 stopserv 仍會使用原始的網域名稱來設定路徑。

解決方案

用於 restore-domain 的網域名稱必須與用於原始的 backup-domain 指令的網域名稱相同。Application Server 8.2 中的 backup-domain 和 restore-domain 指令僅當在同一機器上備份和復原同一網域時有效。

不支援使用其他 JMX 代理程式啟動 Application Server (ID 6200011)

可以在 Application Server 上配置 J2SE 1.4、5.0 和相容版本。啟動 JMX 代理程式是 J2SE 5.0 平台不可或缺的功能。如果您在伺服器啟動時明確設定系統特性，則會啟動此代理程式。

範例值包括下列各項：

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 特性並啟動伺服器後，新的 jmx-connector 伺服器將在 Application Server VM 中啟動。其中一個不好的副作用是管理功能會受到不良影響，並且 Application Server 管理 GUI 和 CLI 可能產生未預期的結果。這些結果是由內建 jmx-connector 伺服器與新的 jmx-connector 伺服器之間的衝突所造成。

解決方案

如果使用的是 jconsole 或其他任何與 JMX 相容的用戶端，請考慮重新使用在 Application Server 啟動時一起啟動的標準 JMX Connector Server。

伺服器啟動時，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 管理指南」。

負載平衡程式配置檔案不是使用任何 Web 服務的端點 URL 建立 (ID 6236544、6275436)

在使用包含 EJB 模組 (用於匯出 Web 服務 URL) 的應用程式設定負載平衡程式配置時，所產生的 loadbalancer.xml 檔案中不包含此 Web 服務的環境根目錄。

解決方案

1. 編輯 loadbalancer.xml 檔案，按照以下所示增加缺少的 Web 模組：

   <web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/>

2. 使用顯示為 EJB 的 Web 服務的環境根目錄名稱替代 context-root-name 值。

配置中的 Java 首頁設定無效 (ID 6240672)

Application Server 網域和伺服器不使用由關聯配置之 java-config 元素的 java-home 屬性指向的 JDK。

解決方案

指定伺服器安裝中所有網域的 Application Server 程序使用的 JDK 由 appserver-installation-dir /config/asenv.conf 檔案決定。該檔案中的 AS_JAVA 特性決定使用的 JDK，並在安裝時設定。安裝完成後，如果 Application Server 程序使用其他 JDK，可修改該值以指向其他 JDK。請注意，該變更會影響此安裝中的所有網域。

由於不會檢查對 asenv.conf 檔案的手動變更是否有效，因此在對其進行變更時請特別留意。修改 AS_JAVA 的值時，檢查 JDK 最低版本需求的產品文件。

使用 sun-appserv-admin 重新啟動 Application Server 時導致 LoginException 錯誤 (ID 6288893)

此問題由 %CONFIG_HOME% 的錯誤值導致。

解決方案

1. 將現有的 asant 重新命名為 asant.bak。

2. 將 as_install /lib/install/templates/ee (對於 SE 或 EE 版本) 中的 asant.template 檔案複製到 as_install /bin/ 目錄，並重新命名 asant 檔案。

3. 編輯新複製的 as_install/bin/asant 檔案，將 %CONFIG_HOME% 記號取代為 as_install /config 值。

4. 如果對原始的 asant.bak 檔案進行了任何手動變更，請將這些變更合併至新的 asant 檔案中。

在 Application Server 文件中未說明 .asadmintruststore 檔案 (ID 6315957)

如果伺服器管理員的 home 目錄中不存在此檔案，則升級在此伺服器上託管的某些應用程式時，可能會遇到嚴重錯誤。

解決方案

• 如果可能，請由安裝此伺服器的使用者執行 asadmin start-domain domain1 指令。

• 如果指令不是由該使用者執行，則應從安裝使用者的 home 目錄中，將 .asadmintruststore 移動或複製到執行使用者的 home 目錄。

• 請注意，如果此檔案是從安裝使用者的 home 目錄移動 (而非複製) 到執行使用者的 home 目錄，可能會遇到應用程式升級問題 (如錯誤 6309079、6310428 和 6312869 中所述)。發生這些問題是因為在升級或安裝使用者的 home 目錄中不包含 .asadminstruststore 檔案。

create-domain 主密碼含有特殊字元時，網域啟動會失敗 (ID 6345947)

當網域的主密碼包含百分比 (%) 字元時，網域將無法啟動。

解決方案

網域的主密碼不應包含百分比字元 (%)。此解決方案適用於建立新網域或變更現有網域之主密碼的情況。

magnus.conf 和 obj.conf 中的負載平衡程式配置變更遭到覆寫 (ID 6394181)

建立安全 http-listener 和安裝 lbplugin 後，會修改 webserver_instance_dir/config 目錄下的 magnus.conf 和 obj.conf 檔案並移除 lbplugin 內容。

在負載平衡程式外掛程式安裝過程中，安裝程式會修改 Application Server 上的 magnus.conf 和 obj.conf 配置檔案。如果您登入 Application Server 管理主控台，並嘗試管理已安裝有負載平衡程式之實例的配置，Application Server 將發出警告訊息，表示其在此配置中偵測到手動編輯。其實此警告指的就是安裝程式所作的變更。

解決方案

請確認尚未覆寫安裝程式所作的變更。

應用程式用戶端

本節介紹已知的應用程式用戶端問題以及相關的解決方案。

封裝在 Application Client Archive 中的程式庫 JAR 會覆寫 MANIFEST 檔案 (ID 6193556)

如果您的用戶端 JAR 內部具有頂層的 JAR 檔案 (在此例中是指 reporter.jar)，當部署用戶端 JAR 時，該 JAR 的 MANIFEST 檔案會覆寫用戶端 JAR 的 MANIFEST 檔案。

解決方案

無。

不支援諸如 CGI-bin 和 SHTML 功能性之類的動態內容技術 (ID 6373043)

不再支援動態內容技術，例如 CGI-bin 和 SHTML。

解決方案

使用 JSP 和 Web 服務技術替代。

隨附的 Sun JDBC 驅動程式

本節介紹已知的附帶的 Sun JDBC 驅動程式問題以及相關的解決方案。

應用程式使用 TRANSACTION_SERIALIZABLE 隔離層級，搭配適用於 Microsoft SQL Server 的隨附 Sun 驅動程式時，會出現當機的情形 (ID 6165970)

如果兩個平行作業事件正在執行，並且其中一個已回復時，使用的是就緒的更新敘述，則可能會遇到此問題。

解決方案

為連線設定隔離層級，在同一隔離層級上建立相對應的連線池。如需有關配置連線池的更多資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」。

PreparedStatement 錯誤 (ID 6170432)

描述 1

如果應用程式在一項作業事件中產生的 PreparedStatement 物件超過 3000 個，則 DB2 可能發生以下錯誤：

[sunm][DB2 JDBC Driver] No more available statements.Please recreate your package with a larger dynamicSections value.

解決方法 1

將以下特性增加到連線池定義中，以確保驅動程式以更大的動態區段值重新連結 DB2 封裝：

createDefaultPackage=true replacePackage=true dynamicSections=1000

如需有關配置連線池的詳細資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」。

描述 2

與 PreparedStatement 錯誤相關，可能會丟出其他錯誤訊息：

[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.

解決方法 2

增大 DB2 伺服器配置參數 APPLHEAPSZ。例如，使用 4096。

描述 3

隔離層級 TRANSACTION_SERIALIZABLE。如果應用程式使用隔離層級 TRANSACTION_SERIALIZABLE，並使用上述建議的其中一個參數，則應用程式在取得連線時可能會當機。

解決方法 3

若要為連線設定隔離層級，必須在該隔離層級建立相對應的連線池。如需說明，請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」。

連接器

本節介紹已知的 J2EE 連接器架構問題以及相關的解決方案。

重新啟動 DAS 實例後，如果將重疊設定為 False，取消部署連接器模組將失敗 (ID 6188343)

在此情況下，獨立的或內嵌的連接器模組便部署在 DAS 和連接器連線區中，並為部署的模組建立了資源。重新啟動 DAS 實例後，將重疊設定為 false 時，取消部署連接器模組會失敗，並顯示以下異常︰

[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023:Error while unloading application [foo]|#]

解決方案

重新啟動 DAS 實例。使用重疊取消部署 (將重疊選項設定為 true) 來取消部署獨立式和內嵌式連接器。

JMS create-jms-resource：CLI 未正確設定預設值 (ID 6294018)

由於使用 asadmin create-jms-resource 指令從指令行建立新 JMS 資源時，無法指定池的最小和最大大小，因此 asadmin 指令應使用預設的池大小值 (最小為 8，最大為 32) 建立資源。從指令行建立資源將導致最小池大小和最大池大小的預設值分別為 1 與 250。

解決方案

從指令行建立 JMS 資源後，使用管理主控台修改池大小的最大、最小值。

說明文件

本節說明已知的文件問題以及相關的解決方案。

Javadoc 不一致

用於多個 AMX 介面與方法的 Javadoc 缺漏或不正確：

• ConnectorConnectionPoolStats 和 AltJDBCConnectionPoolStats 中缺少 NumConnAcquired 和 NumConnReleased 統計的獲取方法。

• 在 EJBCacheStats 中呼叫以下方法將丟出異常： getPassivationSuccesses()、getExpiredSessionsRemoved()、 getPassivationErrors()、getPassivations()。

• 啟動伺服器後，AMX MBeans 可能需要數秒鐘才能完全註冊並可使用。

• 常數 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR 拼字錯誤 (「NNN」)。

隨附的 ANT 丟出 java.lang.NoClassDefFoundError 異常 (ID 6265624)

在「主」執行緒中丟出以下異常 java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher。

解決方案

不建議使用隨附的 ANT 在 Application Server 以外的軟體中執行作業。

記錄選項文件錯誤 (ID 6463965)

「Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide」 中對記錄選項的錯誤敘述如下：

Administration GUI 提供以下兩種記錄選項︰

• 選項 1 – 記錄 stdout ( System.out.print) 內容至事件記錄

• 選項 2 – 記錄 stderr ( System.err.print) 內容至事件記錄

Application Server Enterprise Edition 8.2 中已不存在這些記錄選項。

有關 Application Server 8.2 中 HTTP 檔案快取功能的資訊衝突 (ID 6474799)

Application Server Enterprise Edition 8.2 文件將在「Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide」的 「HTTP File Cache」 中討論 HTTP 檔案快取功能。但是，Application Server Enterprise Edition 8.2 中未包含該功能。請注意，Application Server 9.0 中已重新加入該功能。

高可用性

本節說明已知的高可用性資料庫 (HADB) 問題以及相關聯的解決方案。

hadbm set 不會檢查資源可用性 (磁碟與記憶體空間) (ID 5091280)

使用 hadbm set 增加裝置或緩衝區的大小時，管理系統會在建立資料庫或增加節點時檢查資源的可用性。但是，如果裝置或主記憶體緩衝區的大小變更，系統將不會檢查是否有足夠的資源可用。

解決方案

增加任何 devicesize 或 buffersize 配置屬性之前，驗證所有的主機上是否均有足夠的可用磁碟或記憶體空間。

不支援 packagepath 的異質路徑 (ID 5091349)

您無法在不同主機上以相同名稱但不同位置註冊同一套裝軟體。例如︰

hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
Package successfully registered.
hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
hadbm:Error 22171: A software package has already been registered with 
the package name test.

解決方案

HADB 不支援資料庫叢集中跨節點的不同路徑。請確定 HADB 伺服器安裝目錄 (--packagepath) 在所有參與的主機上均相同。

createdomain 可能會失敗 (ID 6173886、6253132)

在具有多個網路介面的主機上執行管理代理程式時，如果並非所有網路介面均在同一子網路上，則 createdomain 指令可能會失敗：

hadbm:Error 22020: The management agents could not establish a 
domain, please check that the hosts can communicate with UDP multicast.

如果未配置，管理代理程式將使用「第一個」介面進行 UDP 多重播送。「第一個」是根據 java.net.NetworkInterface.getNetworkInterfaces() 的結果所定義的。

解決方案

最佳解決方案是告知管理代理程式要使用的子網路 (請在配置檔案中設定 ma.server.mainternal.interfaces。例如，ma.server.mainternal.interfaces=10.11.100.0 )。或者，也可以將子網路間的路由器配置為路由多重播送資料封包 (管理代理程式使用多重播送位址 228.8.8.8)。

重試對管理代理程式進行新配置之前，您可能必須清除管理代理程式儲存庫。停止網域中的所有代理程式，並刪除儲存庫目錄 (由管理代理程式配置檔案中的 repository.dr.path 識別) 中的所有檔案和目錄。必須先在所有主機上執行此清除作業，然後再使用新配置檔案重新啟動代理程式。

刪除 HADB 實例後，必須清除目錄 (ID 6190878)

刪除 HADB 實例後，隨後嘗試使用 configure-ha-cluster 指令建立新實例的嘗試會失敗。問題在於原始 HADB 實例中的舊目錄仍遺留在 ha_install_dir/rep/* 與 ha_install_dir/config/hadb/instance_name 中。

解決方案

刪除 HADB 實例後，請手動刪除這些目錄。

無法中斷 clu_trans_srv (ID 6249685)

64 位元版本的 Red Hat Enterprise Linux 3.0 中存在錯誤，當執行非同步 I/O 時會強制 clu_trans_srv 程序進入不可中斷模式。這意味著 kill -9 指令無法運作，並且必須重新啟動作業系統。

解決方案

使用 32 位元版本的 Red Hat Enterprise Linux 3.0。

hadbm 不支援含有大寫字母的密碼 (ID 6262824)

將密碼儲存在 hadb 中時，密碼中的大寫字母會被轉換為小寫字母。

解決方案

不使用含有大寫字母的密碼。

階段作業物件逾時並且在管理代理程式中刪除時，hadbm/ma 產生故障錯誤訊息 (ID 6275103)

有時，伺服器上的資源競爭狀態問題可能會導致管理用戶端離線。重新連線時，可能傳回下列誤導性的錯誤訊息「hadbm:Error 22184:A password is required to connect to the management agent」。

解決方案

檢查伺服器上是否發生資源問題，並採取適當的動作 (例如，增加更多資源)，然後重試作業。

管理代理程式不應使用特殊用途介面 (ID 6293912)

不應將具有如 0.0.0.0 之類 IP 位址的特殊用途介面註冊為管理代理程式中 HADB 節點所使用的有效介面。如果 HADB 節點在這些介面上不是透過使用者輸入 hadbm create 指令 (使用主機名稱而非 IP 位址) 設定 ，則註冊此類介面會導致問題。之後節點將無法通訊，並導致 create 指令掛機。

解決方案

在具有多個介面的主機上使用 hadbm create 時，請一律使用 DDN 表示法明確指定 IP 位址。

在 Windows 重新組合失敗 (ID 6291562)

在 Windows 平台上，由於某些配置和負載，作業系統可能會出現大量的重新組合故障。在具有超過 20 個節點的配置中平行執行數個表格掃描 (select *) 時，曾發生此問題。可能的徵狀包括：作業事件經常中斷、修復或回復需要長時間才能完成，以及系統的各個部分經常發生逾時。

解決方案

若要修正此問題，可將 Windows 登錄變數 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 設定為大於預設值 100 的值。為取得最佳效果，請將該值增大到 0x1000 ( 4096)。如需更多資訊，請參閱 Microsoft 支援網頁中的「811003」文章。

執行 hadbm start db_name 時，部分鍵入的密碼未遮罩即顯示 (ID 6303581、6346059、6307497)

當機器超載時，遮罩機制便會失敗，並且會顯示所鍵入密碼的部分字元。如此將導致輕度的安全性風險。應該始終將密碼遮罩。

解決方案

將密碼置於其各自的密碼檔案中 (自 Application Server 8.1 以來建議的方法)，並使用 --adminpassword 或 --dbpasswordfile 選項參照這些檔案。

安裝

本節說明已知的安裝問題以及相關的解決方案。

適用於最小 Application Server 8.x 負載平衡程式的 Java Enterprise System 5 安裝程式無法正確安裝 (ID 6478047)

無法透過 Java ES 5 安裝程式配置 Apache 和 IIS。您需要在 Windows 平台上手動配置 Apache 和 IIS。

解決方案

若要配置負載平衡程式 Apache 或 IIS，請遵循下列步驟。

配置 Apache 2.x：

1. 安裝 Apache 2.x。

   Apache 會安裝到 APDIR=C:\Apache2\Apache2 目錄中。

2. 使用最小安裝來安裝 JES5。

   取消選取負載平衡程式以外的所有元件。Java ES 5 會安裝到 JES5DIR=C:\Program Files\Sun\JavaES5 目錄中。

3. 在 Apache2 目錄中，建立 resource 和 errorpages 目錄。

   mkdir %APDIR%\modules\resource

   mkdir %APDIR%\modules\errorpages

4. 將資源檔案複製到 resource 目錄。

   cd %APDIR%\modules\resource

   copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\LBPlugin*.res .

5. 將負載平衡程式 DLL 複製到 modules 目錄。

   cd %APDIR%\modules

   copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\mod_loadbalancer.dll .

6. 將範本 errorpages 複製到 errorpages 目錄。

   cd %APDIR%\modules\errprpages

   copy %JES5DIR%appserver\lib\webserver-plugin\windows\iws\errorpages .

7. 將負載平衡程式範本和其他 DTD 複製到 Apache config 目錄。

   cd %APDIR%\config

   copy %JES5DIR%\appserver\lib\install\templates\loadbalancer.xml.template .

   copy %JES5DIR%\appserver\lib\dtds\sun-loadbalancer* .

8. 建立 httpd.conf 檔案的備份。

   cd %APDIR%\config

   copy httpd.conf httpd.conf.orig

9. 編輯 httpd.conf 檔案。

   將以下幾行附加到 httpd.conf 檔案中：

   ##BEGIN EE LB Plugin Parameters
   LoadModule apachelbplugin_module modules/mod_loadbalancer.dll
   <IfModule mod_apache2lbplugin.cpp>
   		config-file "C:\Apache2\Apache2/conf/loadbalancer.xml"
   		locale en
   </IfModule>
   <VirtualHost 10.12.8.107>
   DocumentRoot "C:\Apache2\Apache2/htdocs"
   ServerName vm07
   </VirtualHost>
   ##END EE LB Plugin Parameters

10. 將 C:\Apache2\Apache2 替代為實際的 %APDIR% 目錄。

    另請更換 IP、ServerName 和 DocumentRoot 目錄。

11. 在 %APDIR% 中建立新的 sec_db_files 目錄。

    cd %APDIR%

    mkdir sec_db_files

12. 將 NSS 金鑰庫複製到 %APDIR%\sec_db_files 目錄。

    cd %APDIR%\sec_db_files

    copy %JES5DIR%\appserver\lib\webserver-plugin\windows\iis\*.db .

13. 將 PATH 設定為包括必要程式庫。

    前置以下額外的路徑：

    PATH %JES5DIR%\share\lib;%JES5DIR%\appserver\lib;%JES5DIR%\appserver\bin

14. 將 %JES5DIR% 替代為實際的 Java ES 5 目錄。

15. 在系統環境中，增加值為 1 的 NSPR_NATIVE_THREADS_ONLY 變數。

16. 重新啟動並測試 Apache 2 (在配置 loadbalancer.xml 之後)。

配置 IIS LBPlugin：

1. 在 c:\inetpub\wwwroot 目錄中，建立 sun-passthrough 目錄。

   cd c:\inetpub\wwwroot

   mkdir sun-passthrough

2. 在 c:\inetpub\wwwroot\sun-passthrough 目錄中，建立 errorpages、resource 和 sec_db_files 目錄。

   cd c:\inetpub\wwwroot\sun-passthrough

   mkdir errorpages

   mkdir resources

   mkdir sec_db_files

3. 將 DLL 檔案複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.dll c:\inetpub\wwwroot\sun-passthrough\

4. 將 DTD 複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/dtds/sun-loadbalancer*.dtd c:\inetpub\wwwroot\sun-passthrough\

5. 將 sun-passthrough.properties 檔案複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/webserver-plugin/iis c:\inetpub\wwwroot\sun-passthrough\

6. 將安全性 DB 檔案複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.db c:\inetpub\wwwroot\sun-passthrough\sec_db_files\

7. 將資源檔案複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/webserver-plugin/iws/*.res c:\inetpub\wwwroot\sun-passthrough\resource\

8. 將錯誤頁面複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/webserver-plugin/iws/errorpages/*.html c:\inetpub\wwwroot\sun-passthrough\errorpages\

9. 將 loadbalancer.xml.example 範本複製到 sun-passthrough 目錄。

   copy <as_install_dir>/appserver/lib/install/templates/loadbalancer.xml.example c:\inetpub\wwwroot\sun-passthrough\

10. 編輯 sun-passthrough.properties 檔案。

    ##BEGIN EE LB Plugin Parameters
    log-file = C:\InetPub\wwwroot\sun-passthrough\lb.log
    ### The valid options for different logging levels are FATAL, SEVERE, WARNING, INFO and FINE.
    log-level = INFO
    lb-config-file = C:\InetPub\wwwroot\sun-passthrough\loadbalancer.xml
    ##END EE LB Plugin Parameters

如果是配置 IIS6，請務必按照 AS82 文件中所述設定權限，並執行其他步驟。您可能還需要將 IIS6 隔離模式設定為與 IIS5 相容。

安裝期間需要建立 imq 目錄 (ID 6199697)

在 Windows 平台上，安裝 Application Server Enterprise Edition 之後，立即啟動 Message Queue 代理程式會失敗。此時會顯示錯誤訊息，表示目錄 drive:\as\domains\domain1\imq 不存在。

請注意，如果在啟動 domain1 之後啟動此代理程式，則會由 Application Server 建立此目錄並且不會發生此問題。

解決方案

1. 在建立代理程式前建立 var_home_dir_location：

   $imqbrokerd -varhome var_home_dir_location

   例如︰

   $imqbrokerd -varhome D:\as\domains\domain1\imq

J2EE Tutorial

若要在 Sun Java System Application Server Enterprise Edition 8.2 上執行 J2EE 1.4 Tutorial，請執行以下作業：

• 當您依照「About this Tutorial」一章中「About the Examples」小節的說明，編輯檔案範例 /common/build.properties 時，另將連接埠 4848 變更為 4849。

• 使用 Deploytool 時，在部署範例之前增加 localhost:4849。

• 當使用 [管理主控台] 建立任何資源時，請使用 [目標] 標籤將伺服器指定為目標。如果使用指令行或 asant 目標，則伺服器為預設目標，並且無須執行其他動作。

生命週期管理

本節說明已知的生命週期管理問題以及相關的解決方案。

變更 ejb-timer-service 特性時產生錯誤 (ID 6193449)

將 ejb-timer-service 特性 minimum-delivery-interval 設定為 9000 之後，嘗試將 ejb-timer-service 特性 redelivery-interval-in-mills 設定為 7000 會導致 set 指令失敗。此時會顯示以下錯誤訊息：

[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。問題在於 Application Server 驗證 redelivery-interval-in-millis 值是否大於 minimum-delivery-interval-in-millis 值時，所用的驗證檢查機制有錯誤。

解決方案

使用這些特性的預設值，如下所示：

minimum-delivery-interval(default)=7000
redelivery-interval-in-millis(default)=5000

這些預設值以外的值將會產生錯誤。

記錄

本節說明已知的記錄問題以及解決方案。

設定 access.failure 的除錯敘述會導致 Application Server 啟動時當機 (ID 6180095)

設定 JVM 的 java.security.debug 選項將會導致伺服器實例啟動因為死結而凍結；例如，在 domain.xml 中進行以下設定會導致該問題：

<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>

解決方案

無。請避免設定此旗標。

已變更 Java ES 3 Application Server 的記錄位置和實例位置 (ID 6189409)

與版本 7 及相容版本相比，Sun Java System 8.2 中已變更預設記錄和伺服器實例的位置。

如需更多資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」或「Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide」。

Message Queue

本節說明已知的 Java Message Queue 問題以及相關的解決方案。

在與時序相關的情況下，JMS 重新連線無法成功完成 (ID 6173308、6189645、6198481、6199510、6208728)

在與時間相關的方案中重新連線失敗可能是由多個問題導致的。

解決方案

您可以透過以下方法解決這些問題：

• 重新啟動涉及的代理程式

• 重新啟動涉及的 Application Server 實例

從 8.0 至 8.1 Update 2 appclient 中的非同步訊息偵聽程式運作方式已變更 (ID 6198465)

由於最新的變更，當非同步訊息偵聽程式為 app-client 容器中唯一的作用中執行緒時，剩餘的 appclient 虛擬電腦以常駐程式存在。此運作方式對於在 ACC 中執行非同步接收的舊應用程式而言是一種倒退。該問題會影響設定 JMS 訊息偵聽程式並結束主執行緒的應用程式用戶端。

解決方案

請勿結束主執行緒。等待訊息偵聽程式告知主執行緒後，再終止主執行緒。

監視

本節介紹已知的監視問題和相關的解決方案。

整合 Application Server 的監視架構 (6469302)

在 Application Server 後期測試版中，依預設不支援監視架構。

解決方案

若要將監視架構與 Application Server 整合，請遵循以下步驟：

1. 編輯 <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml 檔案。

   使用 Application Server 安裝位置更新 ${InstalledLocation}，使用目前日期更新 ${InstalledDate}。

2. 將 <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml 檔案複製到 <Install_dir>\appserver\lib。

3. 執行 <MFWK_Install_location>\bin\mfwksetup.bat -r <Install_dir>\appserver\lib\com.sun.cmm.as.xml 指令。

其中，${InstalledLocation} 值是 Application Server 的安裝位置，即 c:\Sun\JavaES5\appserver。對於 $InstalledDate，您需要透過計算自 1970 年到目前時間的毫秒數，將時間換算成毫秒。

範例

本節說明與 Application Server 8.2 產品中包含的範例代碼相關的已知問題及其相應的解決方案。

執行 setup-one-machine-cluster 時當機 (ID 6195092)

在 Windows 平台上，mqfailover 指令需要按下 Ctrl+C 鍵才能結束當機程序。您必須重新執行 setup-one-machine-cluster 程序。

從 install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html 執行以下指令：

• 主控台 1

  cd install_dir\samples\ee-samples asant start-mq-master-broker1

• 主控台 2

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker1

• 主控台 3

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker2

• 主控台 4

  cd install_dir\samples\ee-samples asadmin start-domain domain1

如果已針對任何其他 Enterprise Edition 範例執行 asant setup-one-machine-cluster-without-ha 或 asant setup-one-machine-cluster-with-ha，則執行 asant configure-mq。否則，請執行 asant setup-one-machine-cluster-and-configure-mq。在這種情況下，指令顯示成功：

start_nodeagent: [echo] Start the node agent cluster1-nodeagent 
[exec] Command start-node-agent executed successfully.

然後系統會無限期懸置。

解決方案

無。這種問題同樣影響在 Windows 上使用 ant 目標的所有 Enterprise Edition 範例。解決方法是按住 Ctrl+C 退出當機程序，然後再重新執行。

文件未明確表示在執行 Message Queue 容錯移轉範例應用程式之前需要建立 JMS 資源 (ID 6198003)

完成 asadmin 部署說明並執行 Message Queue 容錯移轉範例應用程式後，會顯示以下錯誤訊息：

/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name 
MQFailoverTestClient -textauth -user j2ee -password j2ee
Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA
Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: javax.naming.NameNotFoundException
javax.naming.NameNotFoundException

文件未明確表示如果是使用 asadmin deploy 指令執行手動部署，則必須手動建立 JMS 資源。文件也未提及應該使用所提供的 ant 目標來部署範例應用程式。

解決方案

對於 build.xml 程序檔 (用於建立執行應用程式所需的 JMS 資源)，請使用 asant deploy 目標。

安全性

本節說明與 Application Server 和 Web 應用程式安全性及憑證有關的已知問題和相關解決方案。

無法在含有 J2SE 5.0 的 Enterprise Edition 上執行 WebServiceSecurity 應用程式 (ID 6183318)

WebServiceSecurity 應用程式無法與 J2SE 5.0 協同執行的原因如下：

• J2SE 5.0 PKCS11 不支援 UNWRAP 模式

• J2SE 5.0 PKCS11 不支援 RSA/ECB/OAEPWithSHA1AndMGF1Padding 與 PKCS11 一起執行

解決方案

配合使用 J2SE 1.4.2與任何其他 JCE 提供者 (非依預設所包含的)。請注意，該配置中不存在硬體加速器支援。

SSL 終止無法正常運作 (ID 6269102)

如果已為 SSL 終止配置了負載平衡程式 (硬體)，Application Server 會在重新導向期間將通訊協定從 https 變更為 http。

解決方案

在硬體負載平衡程式與 Application Server 之間增加軟體負載平衡程式。

升級公用程式

本節說明已知的升級公用程式問題和相關聯的解決方案。

範例程序檔使用的 Derby 資料庫建立位置錯誤 (ID 6377804)

該錯誤有兩個層面︰

1. 執行使用 Derby 資料庫的範例應用程式設定程序檔時，在目前目錄或 <install_root>/bin 下便會建立 Derby 資料庫。

2. 範例 build Ant 程序檔可建立 password.txt 檔案，用於儲存目前目錄下的管理密碼檔案，該檔案無法在非根區域和稀疏區域案例中寫入。

解決方案

1. Derby 資料庫位置 – 以 start-database 指令使用 --dbhome 選項，根據 --dbhome 的指定值建立資料庫。例如，以下為用於 start-database 的 asadmin 指令語法。

   start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] [--verbose=false]

2. password.txt 檔案的位置 – 依設計，應可寫入範例目錄，因為所有建立指令均可在該目錄中建立 password.txt 檔案。請確保在可寫入的位置安裝範例的作業備份。

無法使管理員使用者名稱或密碼中的分號 (;) 字元無效 (ID 6473341)

Application Server Enterprise Edition 8.2 安裝不允許在管理使用者名稱中使用特殊字元。如果使用任何特殊字元，網域建立會失敗。但是請注意，管理密碼可能含有特殊字元。

解決方案

從 Application Server 7 升級為 Application Server 8.2 後，請確認管理使用者名稱不包含任何特殊字元。

Web 容器

本節說明已知的 Web 容器問題以及相關的解決方案。

不支援 Apache 和 IIS 使用負載平衡程式外掛程式

Sun Java ES 5 Application Server 不支援在 Apache 和 IIS (非 Sun Web 容器) 上使用負載平衡程式外掛程式。Sun Java ES 會為負載平衡程式外掛程式配置安裝 Sun Java System Web Server。

使用 --precompilejsp=true 部署應用程式會鎖定 JAR 檔案 (ID 5004315)

在 Windows 平台上，如果您在 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't 
be deleted.

解決方案

如果您在部署應用程式時指定 --precompilejsps=false (預設設定)，則不會出現此問題。請注意，第一次使用應用程式會觸發 JSP 編譯，因此第一次請求的回應時間會比以後請求的回應時間長。

還請注意，如果進行預編譯，應先停止並重新啟動伺服器，然後再取消部署或重新部署應用程式。關機會釋放鎖定的 JAR 檔案，因此重新啟動後才能成功取消部署或重新部署。

無法使用基於 Servlet 2.4 且包含空 <load-on-startup> 元素的 web.xml 部署 WAR (ID 6172006)

web.xml 檔案中的選擇性 load-on-startup servlet 元素表示在宣告該 servlet 的 Web 應用程式啟動過程中，將要載入關聯的 servlet 並將其初始化。

該元素的可選內容是一個整數，表示要載入並初始化與 Web 應用程式之其他 servlet 相關的 servlet 的順序。空的 <load-on-startup> 元素表示順序無關緊要，只要是在 servlet 所含 Web 應用程式的啟動過程中將該 servlet 載入並初始化即可。

web.xml 的 Servlet 2.4 模式不再支援空的 <load-on-startup>，這意味著在使用基於 Servlet 2.4 的 web.xml 檔案時，必須指定一個整數。如果指定空 <load-on-startup> (與 <load-on-startup/> 中相同)，web.xml 檔案將無法針對 web.xml 的 Servlet 2.4 模式進行驗證，進而導致部署 Web 應用程式失敗。

向下相容性問題。指定空的 <load-on-startup> 仍可使用基於 Servlet 2.3 的 web.xml。

解決方案

使用基於 Servlet 2.4 的 web.xml 時，指定 <load-on-startup>0</load-on-startup>，以表示 servlet 載入順序並不重要。

無法在資源受限的伺服器上編譯 JSP 頁面 (ID 6184122)

存取 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 中的 fork JSP 配置特性設定為 false：

  <sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app>

任一設定均可防止 Ant 產生新的 javac 編譯程序。

Application Server 不支援 auth-passthrough Web Server 6.1 附加元件 (ID 6188932)

Sun Java System Application Server Enterprise Edition 8.2 還支援 Sun Java System Application Server Enterprise Edition 7.1 具備的 auth-passthrough 外掛程式功能所提供的功能性。但是在 Application Server Enterprise Edition 8.2 中，auth-passthrough 外掛程式功能以不同方式配置。

Application Server Enterprise Edition 7.1 中的 auth-passthrough 外掛程式功能在雙階層部署案例中非常有用，但有以下限制：

• Application Server 實例受公司防火牆後的第二道防火牆保護。

• 不允許任何用戶端直接連線至 Application Server 實例。

在此類網路架構中，用戶端連線至使用 service-passthrough 外掛程式功能配置的前端 Web 伺服器，並將 HTTP 請求轉寄至代理 Application Server 實例進行處理。Application Server 實例只能接收來自 Web 伺服器代理程式伺服器的請求，絕不會直接接收來自任何用戶端主機的請求。因此，部署在查詢用戶端資訊 (如用戶端的 IP 位址) 的代理 Application Server 實例上的任何應用程式均會接收代理主機 IP，因為這才是實際產生所轉送請求的主機。

在 Application Server Enterprise Edition 7.1 中，您可在代理 Application Server 實例上配置 auth-passthrough 外掛程式功能，以便直接為在其上部署的任何應用程式提供遠端用戶端資訊；這就好像代理 Application Server 實例直接接收請求，而不是透過執行 service-passthrough 外掛程式的中間 Web 伺服器接收請求。

在 Application Server Enterprise Edition 8.2 中，您可將 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 特性設為 TRUE 以便啟用 auth-passthrough 功能，如下所示：

<property name="authPassthroughEnabled" value="true"/>

Application Server Enterprise Edition 7.1 中 auth-passthrough 外掛程式功能的安全注意事項同樣適用於 Application Server Enterprise Edition 8.2 中的 authPassthroughEnabled 特性。由於 authPassthroughEnabled 可置換用於認證的資訊 (如產生請求的來源 IP 位址或 SSL 用戶端憑證)，因此，應僅允許受信任的用戶端或伺服器連線至 authPassthroughEnabled 設定為 TRUE 的 Application Server Enterprise Edition 8.2 實例。預防措施是僅配置企業防火牆後方的伺服器，並將 authPassthroughEnabled 設定為 TRUE。可透過網際網路存取的伺服器絕不能將 authPassthroughEnabled 設定為 TRUE。

請注意，在代理 Web 伺服器已配置有 service-passthrough 外掛程式，並且是將請求轉送至 authPassthroughEnabled 設定為 TRUE 的 Application Server 8.1 Update 2 實例情況下，可在該代理 Web 伺服器上啟用 SSL 用戶端認證，並在代理的 Application Server 8.1 Update 2 實例上將其停用。在此情況下，代理的 Application Server 8.1 Update 2 實例仍將請求做為已透過 SSL 認證的請求進行處理，並將用戶端的 SSL 憑證提供給需要此憑證的所有已部署的應用程式。

使用 --enabled=false 建立的 HTTP 偵聽程式不會停用該偵聽程式 (ID 6190900)

使用 --enabled=false 旗標建立 httplistener 時，並未停用偵聽程式。當建立偵聽程式時使用旗標 --enabled 不會產生任何影響。

解決方案

將偵聽程式建立為啟用狀態，稍後手動將其停用。