Web 容器

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

在 Windows 上，使用 --precompilejsp=true 部署應用程式會鎖定應用程式中的 JAR 檔案，進而導致以後的取消部署或重新部署失敗。(ID 5004315)

說明

如果您在 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 並將其初始化為宣告該 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 頁面。(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 的衍生 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 中，可在代理應用程式伺服器實例上配置 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 建立 HTTP 偵聽程式不會停用該偵聽程式。(ID 6190900)

說明

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

解決方案

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

在 Windows 上重新部署失敗，因為 verify_file_user_exists_common 未執行 (ID 6490227)

說明

在 Windows 上，如果要重新部署的應用程式在部署前建立使用者，create-file-user 指令可能會失敗。因為儘管呼叫了 verify_file_user_exists_common，但卻沒有執行，因此無法通知使用者已存在。deploy 目標執行在此時停止，部署與取消部署失敗。

解決方案

首先使用 keydel 目標刪除檔案使用者，然後再次執行 deploy 目標︰

asant keydel
asant deploy