本章說明 Sun Java System Application Server Enterprise Edition 8.2 軟體的已知問題和相關解決方法。如果摘要敘述未指明特定的平台,則所有平台都可能出現此問題。這些資訊按以下章節進行分類:
本節介紹已知的管理問題以及相關的解決方案。
依預設,在 $INSTALL/lib/package-appclient.xml 中,asenv.conf 指向的 domain1 之 AS_ACC_CONFIG 變數有一個程序內定值。如果刪除 domain1 並建立新網域,則不會使用新網域名稱更新 AS_ACC_CONFIG 變數,而造成 package-appclient 程序檔失敗。
執行下列動作之一:
保留 domain1 的完整,並在周圍建立其他網域。
移除 domain1 並使用新網域名稱替代 $INSTALL/lib/package-appclient.xml 中 domain1 的程序內定值。如果 domain1 不存在,則每次建立新的網域均必須執行此作業。
如果您在已安裝了負載平衡器外掛程式 (例如 7.1EE) 的 Application Server 中再安裝負載平衡外掛程式,則 8.2EE 外掛程式將無提示取代任何現有負載平衡器,即使您已建立用於執行該外掛程式的新伺服器實例。
依預設,外掛程式檔案將安裝在 install_dir /plugins/lbplugin 目錄下,這表示任一 Application Server 安裝僅能使用一種版本的外掛程式。請注意,主控台安裝程式將顯示一則訊息,表示正在執行解除安裝,但有時很容易錯過該訊息。
並非所有使用者都會遇到此類問題。如果您的確遇到此問題,請移除舊的 Application Server 安裝並重新安裝而非進行升級安裝。
與 Application Server 7.x 相比,Application Server 8.2 中的 asadmin 指令有若干變更。例如 7.x 中,用來啟動伺服器實例的指令為︰
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」
從 JES2/Application Server 7. x 升級至 JES5/Application Server 8.2 後,您可能會遇到因變更預設連接埠而導致的不相容性問題或錯誤。
請參閱本版本說明中前面的其他需求,以取得 Application Server 8.2 使用的預設連接埠清單。
即使 asadmin restore-domain 指令可提供重新命名網域的選項,仍無法使用原始名稱以外的其他名稱復原網域,因而無法使用 backup-domain 和 restore-domain 指令在同一 Application Server 安裝上執行網域鏡像。重新命名備份的網域看似成功,但嘗試啟動已重新命名的網域卻失敗,因為網域配置中的項目並未變更,並且 startserv 和 stopserv 仍會使用原始的網域名稱來設定路徑。
用於 restore-domain 的網域名稱必須與用於原始的 backup-domain 指令的網域名稱相同。Application Server 8.2 中的 backup-domain 和 restore-domain 指令僅當在同一機器上備份和復原同一網域時有效。
可在 Application Server 上配置 J2SE 1.4.x、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 管理指南」。
若在以使用者「A」的身份登入時執行 asadmin restore-domain 指令,程序檔會以權限 744 (rwxr--r--
) 結束。如果您隨後嘗試以使用者「B」的身份 (即使「B」為超級使用者) 啟動或停止網域,則此操作會失敗,因為僅可對「A」執行這些程序檔。
變更程序檔的權限︰
chmod 755 appserv/domains/domain-name/bin/* |
在使用包含可匯出 Web 服務 URL 之 EJB 模組的應用程式來設定負載平衡器配置時,此 Web 服務的環境根目錄不包含在所產生的 loadbalancer.xml 檔案中。
編輯 loadbalancer.xml 檔案,按照以下所示增加缺少的 Web 模組:
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
使用顯示為 EJB 的 Web 服務的環境根目錄名稱替代 context-root-name 值。
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 最低版本需求的產品文件。
此問題由 %CONFIG_HOME% 的錯誤值導致。
將現有名稱重新命名為 asant.bak。
將 <as_install>/lib/install/templates/ee (對於 SE/EE 版本) 中的 asant.template 檔案複製到 <as_install>/bin/ 目錄中並重新命名 asant 檔案。
編輯新複製的 <as_install>/bin/asant 程序檔,並使用 <as_install>/config 替代 %CONFIG_HOME% 記號。
如果對原始的 asant.bak 檔案進行了任何手動變更,請將這些變更合併至新的 asant 程序檔。
如果伺服器管理員的 home 目錄中不存在此檔案,則升級在此伺服器上代管的某些應用程式時,可能會遇到嚴重錯誤。
如果可能,應由安裝此伺服器的使用者執行 asadmin start-domain domain1 指令。
如果未由該使用者執行,則應從安裝使用者的 home 目錄中將 .asadmintruststore 移動或複製到執行使用者的 home 目錄。
請注意,如果將此檔案從安裝使用者的 home 目錄移動 (而非複製) 到執行使用者的 home 目錄,您可能會遇到應用程式升級問題 (例如在錯誤 6309079、6310428 和 6312869 中說明的問題),因為在升級/安裝使用者 (在 Java ES 中一般為 root) 的 home 目錄中將不再包含 .asadminstruststore 檔案。
當網域主密碼包括百分比字元 (%) 時,網域無法啟動。
網域的主密碼不應包含百分比字元 (%)。當建立新網域或變更現有網域主密碼時,應套用該規則。
建立安全 http-listener 和安裝 lbplugin 後,將修改 webserver_instance_dir/config 下的 magnus.conf 和 obj.conf 檔案,並移除 lbplugin 內容。
負載平衡器外掛程式安裝過程中,安裝程式會修改 Application Server 上的 magnus.conf 和 obj.conf 配置檔案。如果您登入至 Application Server 管理主控台,並嘗試管理已安裝負載平衡器之實例的實例配置,Application Server 將顯示警告訊息,表明其偵測到該配置中的手動編輯。其實此警告指的就是安裝程式所作的變更。
請確認尚未覆寫安裝程式所作的變更。
本節說明 Apache Web Sever 和負載平衡器外掛程式的已知問題和相關解決方案。
編譯和建置 openssl 時,請執行以下指令:
cd openssl-0.9.7e config make |
同樣,對於 Apache 1.3,mod_ssl 來源的目錄名稱取決於所使用的 Apache 發行版本。例如,對於 Apache 1.3.33,名稱為 mod_ssl-2.8.22-1.3.33。
若要執行 Apache 安全性,必須使用憑證。如需有關從憑證授權單位取得憑證的說明,請參閱 modssl FAQ 中有關憑證的資訊。
在 Solaris 上,如果已將 Application Server 安裝在根目錄下,則必須以超級使用者的身份啟動 Apache Web Server。以超級使用者的身份安裝 Java Enterprise System。以超級使用者的身份啟動 Apache 2.0 後,Apache 會切換為您定義的其他使用者並執行。您在 /conf/httpd.conf 檔案中定義了該使用者。若要以超級使用者的身份啟動,則在許多系統上均必須編輯 httpd.conf 檔案,以指定正確的群組。將行:
Group #-1 |
替代為
Group nobody |
有關使用者/群組用法的更多資訊包含在 httpd.conf 檔案中。
安裝 Apache 2.0 和負載平衡程式外掛程式之後,請按照以下說明編輯 ssl.conf 和 sll-std.conf:
將行:
<VirtualHost _default_:9191>
替代為
<VirtualHost machine_name:9191>
其中,machine_name 為電腦的名稱,9191 為安全性連接埠號碼。
本節介紹已知的應用程式用戶端問題以及相關的解決方案。
如果您在用戶端 JAR 內部具有頂層的 JAR 檔案 (此例為 reporter.jar),當您部署用戶端 JAR 時,該 JAR 的 MANIFEST 檔案將覆寫用戶端 JAR 的 MANIFEST 檔案。
目前尚無解決方案。
不再支援動態內容技術,如 CGI-bin 和 SHTML。
改用 JSP 和 Web 服務技術。
本節介紹已知的附帶的 Sun JDBC驅動程式問題以及相關的解決方案。
若要為連線設定所需的隔離層級,必須在相同的隔離層級建立相應的連線區。請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」以取得有關配置連線池的詳細資訊。
如果應用程式在一個作業事件中產生的 PreparedStatement 物件多於 3000 個,則 DB2 可能發生以下錯誤:
[sunm][DB2 JDBC Driver] No more available statements.Please recreate your package with a larger dynamicSections value.
將以下特性增加到連線區定義中,以使用更大的動態區段值來使驅動程式重新連結 DB2 封裝︰
createDefaultPackage=true replacePackage=true dynamicSections=1000
請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」以取得有關配置連線池的詳細資訊。
與上述 PrepardStatement 錯誤相關,可能丟出其他錯誤訊息:
[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.
增大 DB2 伺服器配置參數 APPLHEAPSZ。合適的值為 4096。
隔離層級 TRANSACTION_SERIALIZABLE。如果應用程式使用隔離層級 TRANSACTION_SERIALIZABLE,並使用上述建議的參數之一,則應用程式在取得連線時可能會掛機。
若要為連線設定所需的隔離層級,必須在此隔離層級建立相應的連線區。請參閱「Sun Java System Application Server Enterprise Edition 8.2 管理指南」以取得說明。
在使用準備好的陳述更新時,如果有兩個平行作業事件正在執行,並且其中一個被回復,則配合使用 TRANSACTION_SERIALIZABLE 隔離層級與 Sun 隨附之 Sybase Adaptive Server 驅動程式的應用程式可能會掛機。連線轉返失敗,並顯示以下訊息,且轉返的連線無法再被使用︰
java.sql.SQLException:[sunm][Sybase JDBC Driver]Request cannot be submitted due to wire contention
Sybase Adaptive Server 不支援 TRANSACTION_REPEATABLE_READ 隔離層級。然而,查詢 DatabaseMetaData 時,隨附的 Sun 驅動程式會傳回資料庫支援此隔離層級。使用此隔離層級的應用程式將失敗。
使用隨附的 Sun 驅動程式的應用程式無法設定 TRANSACTION_READ_UNCOMMITTED 隔離層級。在初次存取 DataBaseMetaData 時,應用程式會丟出以下異常:
java.sql.SQLException:[sunm][Sybase JDBC Driver][Sybase]The optimizer could not find a unique index which it could use to perform an isolation level 0 scan on table 'sybsystemprocs.dbo.spt_server_info'.
目前尚無解決方案。
當使用 SUN JDBC Oracle 資料來源 (com.sun.sql.jdbcx.oracle.OracleDataSource) 時,在 JDBC 連線池上設定以下特性:
<property name="serverType" value="dedicated"/>
該特性的值取決於配置 Oracle 伺服器偵聽程式的方式。如果在「共用」模式中配置該偵聽程式,則上述值需變更為「dedicated」。
從 JDBC 10.2 驅動程式開始,在 CLASSPATH 中有多個 JDBC jar 檔案可能會導致 java.lang.SecurityException: Sealing violation exception。
以下 Oracle 文件 ID 記載了 Oracle 的詳細說明:
注意:405446.1 主旨:JDBC 驅動程式 10.2 使用封簽的 JAR 檔案,可能導致 SecurityException 封簽違規
(Oracle 的建議) 請確定 CLASSPATH 僅包含一個 JDBC 驅動程式 JAR 檔案。
本節介紹已知的 J2EE 連接器架構問題以及相關的解決方案。
在此情況下,獨立的或內嵌的連接器模組便部署在 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) 來取消部署獨立的和內嵌的連接器。
由於使用 asadmin create-jms-resource 指令從指令行建立新 JMS 資源時,您無法指定最小和最大池大小,因此假設 asadmin 指令使用預設的池大小值 (最小 8,最大 32) 來建立資源。但是,情況並非如此。從指令行建立資源將導致最小池大小和最大池大小的預設值分別為 1 與 250。
從指令行建立 JMS 資源後,使用管理主控台修改池大小的最大、最小值。
本節說明已知的文件問題以及相關的解決方案。
用於多個 AMX 介面與方法的 Javadoc 缺漏或不正確:
ConnectorConnectionPoolStats 和 AltJDBCConnectionPoolStats 中缺少 NumConnAcquired 和 NumConnReleased 統計的獲取方法。這些獲取方法將在未來的發行版本中加入為 getNumConnAcquired() 和 getNumConnReleased()。
在 EJBCacheStats 中呼叫以下方法將丟出異常:getPassivationSuccesses()、getExpiredSessionsRemoved()、getPassivationErrors() 和 getPassivations()。這將在未來的版本中進行修正。
啟動伺服器後,AMX MBeans 可能需要數秒鍾才能完全註冊和使用。未來的版本將可能確定完全載入 AMX MBeans 的時間。
常數 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR 拼字錯誤 (「NNN」)。這將在未來的版本中進行校正。
執行緒 main 中丟出以下異常: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher。
不建議將隨附的 ANT 用於 Application Server 以外的軟體。
「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 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 中已重新加入該功能。
由於其他缺陷 (可能是 6295215),「Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide」中的「Obtaining a Physical Connection from a Wrapped Connection」小節中所提供的程式碼不正確。具體來說,下行:
Connection drivercon = ds.getConnection(con); |
應改為:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
本節說明已知的高可用性資料庫 (HADB) 問題以及相關的解決方案。
在兩個子網路上配置為具有雙網路的 HADB,在 Solaris SPARC 上工作正常。然而,我們發現由於作業系統的問題或同一硬體平台上的網路驅動程式,Solaris x86 與 Linux 平台並不總能正確處理雙網路。這將引起 HADB 的以下問題:
在 Linux 上,在傳送訊息時會封鎖某些 HADB 程序。這將引起 HADB 節點重新啟動和網路分割。
在 Solaris x86 上,網路故障後會出現一些問題,這會阻止切換至其他網路介面。這種情況不會經常發生,因此最好還是具有兩個網路。這些問題中的一部分在 Solaris 10 中得到解決。
不支援幹線。
HADB 在 Windows 2003 上不支援雙網路 (ID 5103186)。
建立新資料庫可能失敗並顯示以下錯誤,表示可用的共用記憶體區段不足:
HADB-E-21054:System resource is unavailable:HADB-S-05512:Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message:Too many open files.
驗證是否已配置共用記憶體,以及配置是否能夠正常工作。尤其,在 Solaris 8 上,檢視檔案 /etc/system,並檢查變數 shmsys:shminfo_shmseg 的值是否至少為每個主機上節點數目的六倍。
當 Intimate Shared Memory 建立及附加至共用記憶體區段時,HADB 4.3-0.16 及更新版本會配置為使用 Intimate Shared Memory (使用 SHM_SHARE_MMU 旗標)。使用此旗標基本上會在實體記憶體中鎖定共用記憶體區段,以避免共用記憶體區段遭到分頁。這在安裝低階機器時很容易造成問題。
因此,若開發者在使用 Application Server 7.0 EE 的機器上有 512 MB 的記憶體和許多可用的交換空間,之後再安裝 7.1 EE 或更新版本,則開發者將會在配置預設 clsetup 叢集 (建立兩個 HADB 節點,每個節點的 devicesize 為 512) 時發生問題,而導致沒有足夠的實體 RAM 可支援這兩個節點皆所需的共用記憶體。
請務必在並置應用程式伺服器和 HADB 時,具備建議的記憶體容量。請參閱HADB 需求和支援的平台以取得更多資訊。
當使用 hadbm set 增加裝置或緩衝區大小時,管理系統會在建立資料庫或增加節點時檢查資源可用性,但不會在裝置或主記憶體緩衝區大小變更時檢查是否有足夠的可用資源。
增加任何 devicesize 或 buffersize 配置屬性之前,驗證所有的主機上是否有足夠的可用磁碟/記憶體空間。
不可能在不同主機的不同位置使用相同名稱註冊同一套裝軟體,例如:
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) 在所有參與的主機上均相同。
當在具有多個網路介面的主機上執行管理代理程式時,如果部分網路介面不在同一個子網路中,則 create domain 指令可能失敗:
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 實例之後,嘗試使用 configure-ha-cluster 指令建立新實例失敗。問題在於,原始 HADB 實例在 ha_install_dir/rep/* 和 ha_install_dir/config/hadb/instance_name 中留下了舊目錄。
請務必於刪除 HADB 實例之後,手動刪除這些目錄。
在 Solaris 10 作業系統上,使用 hadbm 指令啟動、停止或重新配置 HADB 可能會失敗或當機,並顯示下列錯誤之一:
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
當讀取/寫入 clu_noman_srv 程序使用的檔案 (nomandevice) 不一致時,可能發生此情況。可透過在 HADB 歷史檔案中尋找以下訊息來偵測此問題:
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start. |
由於無法手動再現此問題,因此下列的解決方法尚未經過驗證。但是,對受影響的節點執行此指令應該可以解決此問題。
hadbm restartnode --level=clear nodeno dbname |
請注意,該節點的所有裝置均會被重新初始化。重新初始化之前,您可能必須停止節點。
在安裝了數個 NIC 卡並執行 Solaris 8 的主機上啟動時,如果同時包含已啟用 IPv6 和 IPv4 的卡,則會終止管理代理程式,並顯示異常 "IPV6_MULTICAST_IF failed."。
將環境變數 JAVA_OPTIONS 設定為 -Djava.net.preferIPv4Stack=true,例如:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
或者,使用 Solaris 9 或更高版本,其不會出現該問題。
在 64 位元版本的 Red Hat Enterprise Linux 3.0 中存在一個錯誤,可在執行非同步化 I/O 時導致 clu_trans_srv 程序在不可中斷模式中結束。這意味著強制結束 -9 不能解決問題,必須重新啟動作業系統。
使用 32 位元版本的 Red Hat Enterprise Linux 3.0。
將密碼儲存在 hadb 中時,密碼中的大寫字母會被轉換為小寫字母。
不使用含有大寫字母的密碼。
當降級至舊的 HADB 版本時,管理代理程式可能會失敗,並顯示不同錯誤代碼。
雖然可以降級 HADB 資料庫,但是如果已變更了儲存庫物件,則管理代理程式可能無法降級。降級後,必須使用最新版的 HADB 中的管理代理程式。
關於安裝/移除 HADB c 套裝軟體 (Solaris:SUNWhadbc,Linux:sun-hadb-c) 版本 <m.n.u-p>,symlink /opt/SUNWhadb/<m> 自建立後將永遠不會變更。因此,可能存在孤立的 symlink。
如果不使用,請在安裝之前或解除安裝之後刪除 symlink。
在 Solaris 10 上,透過使用全域區域中的 ma-initd 程序檔停止管理代理程式時,也會停止本機區域中的管理代理程式。
不同時在全域區域和本機區域中安裝管理代理程式。
有時,伺服器上的資源競爭問題可能導致管理用戶端的連線中斷。重新連線時,顯示誤導使用者的錯誤訊息 "hadbm:Error 22184:A password is required to connect to the management agent"。
檢查該伺服器上是否存在資源問題,並採取適當措施 (例如,增加更多資源),然後重試該作業。
使用 Java Enterprise System (以超級使用者的身份) 安裝 HADB 後不允許非超級使用者管理 。
始終以超級使用者身份登入以管理 HADB。
不應將包含 0.0.0.0 之類 IP 位址的具有特殊用途的介面註冊為管理代理程式中的 HADB 節點所使用的有效介面。如果透過使用者使用主機名稱而非 IP 位址發出 hadbm create 指令,在此類介面上設定 HADB 節點,則註冊此類介面可能會導致問題發生。之後節點將無法通訊,並導致 create 指令掛機。
當在包含多重介面的主機上使用 hadbm create 時,請始終使用 DDN 表示法明確指定 IP 位址。
在 Windows 平台上,由於某些配置和負載,作業系統中可能會出現大量的重新組合故障。在具有多於二十個節點的配置平行執行數個表掃描 (select *) 時,曾發生此問題。此問題表現為作業事件頻繁中斷、修復或回復需較長時間才能完成,以及多種系統零件可能會頻繁逾時。
若要修正此問題,可將 Windows 登錄變數 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 設定為大於預設值 100 的值。建議您將此值提高到 0x1000 (4096)。如需更多資訊,請參閱 Microsoft 支援頁面中的文章 811003。
有可能是機器負載了會讓遮罩機制失敗的工作,而導致輸入的密碼有部分字元顯露。如此會造成輕微的安全性風險,因此密碼應一律遮罩。
將密碼置於其所擁有的密碼檔案中 (Application Server 8.1 之後的版本一般會建議使用此方法),並使用 --adminpassword 或 --dbpasswordfile 選項參照密碼。
當 Application Server 安裝在 Solaris 全域區域中的 /usr/SUNWappserver 時,稀疏本機區域無法使用以此 Application Server 實例安裝的 HADB 元件。
發生此問題是由於 HADB 已安裝在全域區域的 /opt/SUNWhadb 中,但是該目錄無法從稀疏本機區域讀取。不幸的是,無法在 JES5 中重新放置 HADB 束。
由於無法重新放置 Application Server HADB 元件,所以 HADB 元件必須分別安裝在每個要能存取 HADB 的稀疏本機區域中。
本節說明已知的安裝問題以及相關的解決方案。
已在多個 Linux 系統中發現此問題。此問題在 Java Desktop System 2 中最為常見,也見於 Linux Red Hat 發行軟體中。
在最後的安裝程式螢幕上按一下 [完成] 按鈕之後,安裝程式無法啟動包含產品 [關於] 頁面或產品註冊頁面的瀏覽器視窗,且無限期當機,並不返回指令提示。
在啟動安裝程式的終端機視窗中按下 Ctrl+C 以結束安裝程式。執行完此步驟後,有時會啟動包含產品 [關於] 頁面或註冊頁面的瀏覽器視窗,但如果未顯示該視窗,請啟動瀏覽器並輸入以下 URL 以檢視 [關於] 頁面:
file://install_dir/docs-ee/about.html |
如果您還選取安裝選項以註冊產品,請使用產品 [關於] 頁面上的連結進入註冊頁面。
在 Windows 上,Application Server Enterprise Edition 安裝一經完成,Message Queue 代理程式便會啟動失敗,並顯示訊息表明 drive:\as\domains\domain1\imq 目錄不存在。
請注意,如果在啟動 domain1 之後啟動此代理程式,則 Application Server 會建立此目錄並且不會發生此問題。
在建立代理程式前建立 var_home_dir_location:
$imqbrokerd -varhome var_home_dir_location |
例如︰
$imqbrokerd -varhome D:\as\domains\domain1\imq |
如果系統上沒有安裝 compat-libstdc++ 程式庫,則在 Red Hat Linux Advanced Server (RHLAS) 3.0 或 4.0 系統上安裝 Application Server Enterprise Edition 8.2 時會失敗。Application Server 需要 RHLAS 系統上必須有 compat-libstdc++ 程式庫,但預設並不會安裝此程式庫。請注意,只有 RHLAS 系統上會發生此問題。
安裝 Application Server 軟體之前,請從 http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html 下載並安裝 compat-libstdc++ RPM。
當以 64 位元模式使用 Web Server 7.0 執行 Application Server Enterprise Edition 8.2 時,嘗試執行負載平衡器外掛程式的 64 位元版本因以下錯誤失敗︰
failure: CORE2253: Error running Init function load-modules: dlopen of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/ lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32) failure: server initialization failed |
發生此問題是由於無適用於 Application Server Enterprise Edition 8.2 的 64 位元負載平衡器外掛程式,而 64 位元 Web Server 需要 64 位元外掛程式。
使用以下指令即可判斷 Web Server 是以 64 位元還是 32 位元模式執行︰
wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform |
目前沒有開發 Application Server Enterprise Edition 8.2 的 64 位元負載平衡器計畫。若要解決此問題,請使用 Web Server 7.0 反向代理功能,或將 Web Server 7.0 重新配置為以 32 位元模式執行。請參閱 Web Server 文件以取得說明。
當在 Windows 2000 的預設位置上安裝 Application Server 8.2 時,執行 asant deploy 可能會遇到以下錯誤︰
$ C:/Sun/JavaES5/appserver/bin/asant deploy The input line is too long. The syntax of the command is incorrect. |
發生此問題是由於 Windows 2000 中的指令行不得超過 1000 個字元,根據您的系統配置,預設 ANT_OPTS 環境可能導致 asant deploy 指令行過長。此問題僅出現在 Windows 2000 上。
在 Windows 2000 上請使用非常簡短的目錄路徑安裝 Application Server (例如 C:\JES5_AS)。
在 Windows 上使用 JES 5 b12 時,如果在所選元件安裝面板的最上層選取了 Application Server,則預設也會選取「節點代理程式」子元件。安裝程序接著會建立節點代理程式,以及屬於此節點代理程式之名為 AppServer1 的伺服器實例。這是正確的運作方式。
然而,如果取消選取「節點代理程式」子元件,安裝程序仍會在網域的 common.properties 檔案中建立 AppServer1 實例;例如:
domain.name=domain1 appserver.instance=AppServer1 |
後續使用 asant 來部署應用程式的嘗試將會失敗。
編輯 common.propeties 檔案,將 appserver.instance=AppServer1 取代為 appserver.instance=server。
由於其他缺陷 (可能是 6295215),「Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide」中的「Obtaining a Physical Connection from a Wrapped Connection」小節中所提供的程式碼不正確。具體來說,下行:
Connection drivercon = ds.getConnection(con); |
應改為:
Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con); |
在此版軟體中,Application Server 不支援網路檔案系統 (NFS)。
無。
若要在 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 目標,則伺服器為預設目標,無需其他動作。
本節說明已知的生命週期管理問題以及相關的解決方案。
[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
這些預設值以外的值將會產生錯誤。
本節說明已知的記錄問題以及解決方案。
設定 JVM 的 java.security.debug 選項將會導致伺服器實例啟動因為死結而凍結;例如,在 domain.xml 中進行以下設定會導致該問題:
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
目前尚無解決方案。請避免設定此標幟。
與 7.x 相比,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」。
本節說明已知的 Java Message Queue 問題以及相關的解決方案。
在與時間相關的方案中重新連線失敗可能是由多個問題導致的。
您可以透過以下方法解決這些問題:
重新啟動涉及的代理程式
重新啟動涉及的 Application Server 實例
由於最新的變更,當非同步訊息偵聽程式為 app-client 容器中唯一的作用中執行緒時,剩餘的 appclient 虛擬電腦以常駐程式存在。此運作方式對於 ACC 中執行非同步接收的舊應用程式是一種回歸。該問題會影響設定 JMS 訊息偵聽程式並結束主執行緒的應用程式用戶端。
請勿結束主執行緒。等待訊息偵聽程式告知主執行緒後,再終止主執行緒。
本節介紹已知的監視問題和相關的解決方案。
如果您使用監視層級設定頁面將連接器服務或連接器連線池監視層級變更為 LOW 或 HIGH,然後儲存,則兩者均不會在網域的 domain.xml 檔案中變更。但是,如果您將 JMS 服務監視層級變更為 LOW 或 HIGH,然後儲存,則會同時變更連接器服務和連接器連線池的值。執行指令行中的等效指令不會發生此問題。
在監視層級頁面上只能使用 JMS 服務元件來變更監視層級。
當檢視 HTTP 服務中某些元素的監視統計時,某些顯示的值與目前值不對應,或始終為 0。具體來說,下列 HTTP 服務統計不顯示適用於 Application Server 的資訊,應該將其忽略:
http-service load1MinuteAverage load5MinuteAverage load15MinuteAverage rateBytesTransmitted rateBytesReceived
pwc-thread-pool (元素)
例如︰
EJBModuleMonitorMap().size() = 1 eventhough ejb module is undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01 |
EJB 模組與應用程式也一樣。雖然是有計劃地 (透過 MBean API) 並且透過 asadmin list/get 移動監視名稱下的所有統計訊,但空監視 MBean 依然存在。
asadmin list -m "server.applications" shows the following output: server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui server.applications._export_install_nov-11_domains_domain1_applications _j2ee-modules_sqe_ejb_s1_01 |
您可以查看下列統計資訊:
bin/asadmin list -m "server.applications._export_install_nov-11_domains _domain1_applications_j2ee-modules_sqe_ejb_s1_01" server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.SQEMessage server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01.TheGreeter |
取消部署後:
_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_ ejb_s1_01 |
如果執行某項 list 指令,仍可看到下列應用程式:
asadmin list -m "server.applications" server.applications.MEjbApp server.applications.__ejb_container_timer_app server.applications._export_install_nov-11_domains_domain1_applications_ j2ee-modules_sqe_ejb_s1_01 server.applications.adminapp server.applications.admingui server.applications.com_sun_web_ui |
但不包含任何監視統計資訊:
asadmin list -m "server.applications._export_install_nov-11_domains_ domain1_applications_j2ee-modules_sqe_ejb_s1_01" Nothing to list at server.applications.-export-install-nov-11-domains- domain1-applications-j2ee-modules-sqe-ejb-s1-01. |
若要取得以字串開頭的有效名稱,請使用萬用字元 (「*」)。例如,若要列示以 server 開頭的所有監視實體的名稱,請使用 list "server.*"。
此項是無害的。可以安全地重新部署模組,不會出現任何問題。雖然沒有移除根監視 Mbean,但它為空監視。
本節說明與 Java 資料物件和容器管理持續性相關的已知和關聯的解決方案
如果在作業事件中修改 (或建立) 實例之間的外來鍵鏈相依性,而導致資料庫中產生循環相依性,便會發生此異常。
將一組原始作業分割成多個作業事件。
本節介紹與 PointBase 相關的已知及其相應解決方案。
對於指向 PointBase 資料庫安裝的 JDBC 連線池,將 transaction-isolation-level 池屬性設定為除預設值 (Connection.TRANSACTION_READ_COMMITTED) 之外的任何值,均會導致異常。但對於指向其他資料庫的連線區,將同一參數設定為非預設值卻不會拋出異常。
對於指向 PointBase 資料庫安裝的 JDBC 連線池,請勿嘗試設定 transaction-isolation-level。
如果同時使用網路伺服器驅動程式與內嵌式驅動程式,那麼附帶的 PointBase 有時會拋出異常。
請單獨使用內嵌式驅動程式或單獨使用網路伺服器驅動程式,切勿同時使用。
升級至 Application Server Enterprise Edition 8.2 後,更新發行版本修補程式會覆寫 Pointbase 預設資料庫。
重新建立或重新輸入升級前存在的任何方案或資料。如果您使用具有 [產生表] 選項的 CMP Bean 部署應用程式,則必須取消部署或重新部署應用程式才能產生表。
本節說明與 Application Server 8.2 產品中包含的範例代碼相關的已知及其相應的解決方案。
如果您執行以下指令,請參閱 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 登出當機程序,然後再重新執行。
拋出的錯誤如下:
/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 部署目標。
在 Linux 上部署 install_dir/samples/webservices/security 範例 (basicSSl) 時,並未建立憑證,並且丟出如下類似錯誤:
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
問題是 NSS 程式庫在 Linux 安裝中的位置與在 Solaris 安裝中的位置不同。在 Linux 上進行部署時,您需要確認 LD_LIBRARY_PATH 指向了正確的 NSS 程式庫。在您所處的環境中,或在 install_dir/bin/asant shell 包裝程式程序檔中設定 LD_LIBRARY_PATH。
執行下列動作之一:
設定 LD_LIBRARY_PATH=/opt/sun/private/lib。
將以下行增加到 install_dir/bin/asant 程序檔中:
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
從 Application Server Platform Edition 8.0 升級為 Application Server Enterprise Edition 8.2 後,嘗試存取該範例頁面時,您可能會收到一個 HTTP 404「找不到檔案」錯誤。
將範例文件從 8.0 網域複製到 8.2 網域。
如果 Solaris 全域區域中已安裝 Application Server Enterprise Edition 8.2,且隨後在稀疏本機區域中安裝了 Application Server 網域,如果部署程序期間,稀疏區域中網域的檔案權限未充分開啟,則當執行範例應用程式時,您可能會遇到某些問題。
部署程序期間,請確保 Application Server 能夠擷取用戶端 JAR 檔案 xmsClient.jar,並將其複製到範例位置 (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar)。通常該作業可由範例工具自動完成,但是如果 xmsClient.jar 上的權限未開啟,則會失敗。
本節說明與 Application Server 和 Web 應用程式安全性及憑證有關的已知問題和相關解決方案。
WebServiceSecurity 應用程式無法與 J2SE 5.0 一起執行,因為:
J2SE 5.0 PKCS11 不支援 UNWRAP 模式
J2SE 5.0 PKCS11 不支援 RSA/ECB/OAEPWithSHA1AndMGF1Padding 與 PKCS11 一起執行
J2SE 團隊已將此錯誤歸檔為「CR 6190389:為 RSA-PKCS1 與 RSA-OAEP wrap/unwrap 機制新增支援」。
配合使用 J2SE 1.4.2與任何其他 JCE 提供者 (非依預設所包含的)。請注意,該配置中不存在硬體加速器支援。
如果已為 SSL 終止配置了負載平衡程式 (硬體),Application Server 會在重新導向期間將通訊協定從 https 變更為 http。
在硬體負載平衡器與 Application Server 之間增加軟體負載平衡器。
本節介紹已知的升級公用程式問題和相關的解決方案。
當執行升級公用程式,並將 install_dir 識別為來源安裝目錄時,升級程序僅升級在 install_dir/domains 目錄下建立的網域。在其他位置建立的網域不會進行升級。
在啟動升級程序之前,將不同位置的所有網域目錄複製到 install_dir/domains 目錄中。
此問題已在多個 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
如果您還選取安裝選項以註冊產品,請使用產品 [關於] 頁面上的連結進入註冊頁面。
從目標 domain.xml 中移除以下項目 (升級後),然後重新啟動伺服器:
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
從 Application Server 7.x 升級為 8.2 時,在新舊安裝間可能發生連接埠衝突,最有可能是預設連接埠 8080 與 8181。
變更 Application Server 8.2 使用的連接埠以解決連接埠衝突。
該錯誤有兩個層面︰
執行使用 Derby 資料庫的範例應用設定程式程序檔時,Derby 資料庫將建立在目前目錄或 <install_root>/bin 下。
範例 build Ant 程序檔可建立 password.txt 檔案,以儲存目前目錄下的管理密碼檔案,該檔案無法在非 root 或稀疏區域情形中寫入。
Derby 資料庫位置 – 以 start-database 指令使用 --dbhome 選項,根據 --dbhome 的指定值建立資料庫。例如,以下為用於 start-database 的 asadmin 指令語法。
start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] [--verbose=false] |
password.txt 檔案的位置 – 依預設應可寫入範例目錄,因為所有建立指令均可在該目錄中建立 password.txt 檔案。請確保在可寫入的位置安裝範例的作業備份。
當您使用管理員憑證而非預設憑證執行升級安裝時,將發生此問題。
當使用基於檔案的安裝程式將 8.xPE 同時升級為 8.2EE 時,請對新 Application Server 使用以下管理員憑證︰
管理員使用者︰admin
管理員密碼︰adminadmin
主密碼︰changeit
執行升級後,您可以根據需要變更這些密碼。
升級工具未能偵測到 [來源目錄] 欄位的現有但無效的目錄輸入,從而讓人以為目錄配置是正確的。
應有的行為是來源目錄的路徑輸入錯誤時,將快顯「無效目錄」訊息。為來源目錄輸入 /opt/SUNWappserverEE81UR2/ 後,會正常快顯無效目錄的資訊。然而,當輸入 /opt/SUNWappserverEE81UR2/domains 後,即使路徑無效,該工具仍繼續升級程序而不發出警告。除運作方式因輸入值不同而異之外,此問題與 ID 6440710 相似。
將 Application Server 7 或 8.x 升級為 Application Server 8.2 時,必須首先使用文件建議的值編排來源目錄︰現地升級的網域根目錄與同時升級的網域目錄。
Application Server Enterprise Edition 8.2 安裝不允許在管理使用者名稱中使用特殊字元。如果使用了任何特殊字元,則網域建立將失敗。但是請注意,管理密碼可能含有特殊字元。
從 Application Server 7 升級為 Application Server 8.2 後,請確認管理使用者名稱不包含任何特殊字元。
本節說明已知的 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't be deleted. |
如果您在部署應用程式時指定 --precompilejsps=false (預設的設定),則不會出現此問題。請注意,第一次使用應用程式將觸發 JSP 編譯,因此第一次請求的回應時間會比以後的請求的回應時間長。
還請注意,如果進行預編譯,應先停止並重新啟動伺服器,然後再取消部署或重新部署應用程式。關機會釋放鎖定的 JAR 檔案,因此重新啟動後才能成功取消部署或重新部署。
web.xml 中的選擇性 load-on-startup servlet 元素表示要載入相關的 servlet 並將其初始化為宣告該 servlet 的 Web 應用程式啟動的一部分。
該元素的可選內容是一個整數,表示要載入並初始化與 Web 應用程式之其他 servlet 相關的 servlet 的順序。只要在啟動其含有的 Web 應用程式過程中載入並初始化 servlet,空的 <load-on-startup> 即表示順序錯誤。
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 頁面後無法編譯,且伺服器記錄含有錯誤訊息「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 的衍生 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 編譯程序。
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 中,可在代理應用程式伺服器實例上配置 auth-passthrough 外掛程式功能,以直接為在其上部署的所有應用程式提供遠端用戶端資訊;這就好像代理應用程式伺服器實例直接接收請求,而不是透過執行 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。
請注意,如果在分析藍本中已使用 service-passthrough 外掛程式配置了 Web 代理伺服器,並且該伺服器將請求轉送至 authPassthroughEnabled 設定為 TRUE 的 Application Server 8.1 Update 2 實例,則 SSL 用戶端認證可在該 Web 代理伺服器上啟用,並可在代理 Application Server 8.1 Update 2 實例上停用。在此情況下,代理 Application Server 8.1 Update 2 實例仍將請求作為已透過 SSL 認證的請求進行處理,並將用戶端的 SSL 憑證提供給需要此憑證的所有已部署的應用程式。
使用 --enabled=false 旗標建立 httplistener 時,並未停用偵聽程式。當建立偵聽程式時使用旗標 --enabled 不會產生任何影響。
將偵聽程式建立為啟用狀態,稍後將其手動停用。
在 Windows 上,如果要重新部署的應用程式在部署前建立使用者,create-file-user 指令可能會失敗。因為儘管呼叫了 verify_file_user_exists_common,但卻沒有執行,因此無法通知使用者已存在。deploy 目標執行在此時停止,部署與取消部署失敗。
首先使用 keydel 目標刪除檔案使用者,然後再次執行 deploy 目標︰
asant keydel asant deploy |