Web 容器

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

在 Windows 上，使用 --precompilejsp=true 部署應用程式可能會鎖定該應用程式中的 JAR 檔案，從而導致後面的取消部署或重新部署作業失敗 (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 的 web.xml (包含空的 <load-on-startup> 元素) 部署 WAR (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 頁面 (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 附加元件 (6188932)

說明

Sun Java System Application Server 9.1 增加了對 Sun Java System Application Server Enterprise Edition 7.1 上 auth-passthrough 外掛程式功能所提供之功能性的支援。但是，在 Application Server 9.1 中，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 中，auth-passthrough 外掛程式功能可以在代理 Application Server 實例上配置，以使該實例上部署的所有應用程式都能直接取得遠端用戶端的資訊；猶如代理 Application Server 實例直接收到請求一樣，而非透過執行 service-passthrough 外掛程式的中間 Web 伺服器接收。

在 Application Server 9.1 中，auth-passthrough 功能可以透過將 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 特性設定為 TRUE 來啟用，如下所示：

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

對 Application Server Enterprise Edition 7.1 中 auth-passthrough 外掛程式功能的安全考慮也適用於 Application Server 9.1 中的 authPassthroughEnabled 特性。由於 authPassthroughEnabled 允許置換可用於認證的資訊 (如發出請求的 IP 位址，或 SSL 用戶端憑證)，因此，必須僅允許可信任的用戶端或伺服器連線至 authPassthroughEnabled 設定為 TRUE 的 Application Server 9.1 實例。做為預警措施，建議您應僅將公司防火牆後伺服器的 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 憑證提供給需要此憑證的所有已部署的應用程式。