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」。

有兩種方法可以執行此操作：

• 將 domain-dir/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 編譯的新程序。

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

說明

Sun GlassFish Enterprise Server 2.1.1 新增支援 Sun GlassFish Enterprise Server Enterprise Edition 7.1 上 auth-passthrough 外掛程式功能所提供的功能。但是在 Enterprise Server 2.1.1 中，auth-passthrough 外掛程式功能的配置方式則不同。

Enterprise 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 外掛程式功能，以使該實例上部署的所有應用程式都能直接取得遠端用戶端的資訊；猶如代理應用程式伺服器實例直接收到請求一樣，而非透過執行 service-passthrough 外掛程式的中間 Web 伺服器接收。

在 Enterprise Server 2.1.1 中，將 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 特性設定為 TRUE 即可啟用auth-passthrough 功能，如下所示：

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

Application Server Enterprise Edition 7.1 中 auth-passthrough 外掛程式功能的安全性注意事項，也同樣適用於 Enterprise Server 2.1.1 中的 authPassthroughEnabled 特性。由於 authPassthroughEnabled 能夠置換可以用於認證的資訊 (例如發出請求的 IP 位址或 SSL 用戶端憑證)，因此必須只在 authPassthroughEnabled 設定為 TRUE 的情況下，才能允許信任的用戶端或伺服器連線至 Enterprise Server 2.1.1 實例。作為預警措施，建議您應僅將公司防火牆後的伺服器的 authPassthroughEnabled 設定為 TRUE。可透過網際網路存取的伺服器永遠不能將 authPassthroughEnabled 設定為 TRUE。

請注意，若是將代理 Web 伺服器配置成使用 service-passthrough 外掛程式，同時將 authPassthroughEnabled 設定為 TRUE 以便將請求轉寄至 Enterprise Server 實例的情形，則可在 Web 代理伺服器上啟用 SSL 用戶端認證功能，並在代理的 Enterprise Server 實例上停用此功能。在此情況下，代理 Enterprise Server 實例仍會將請求視為已透過 SSL 進行認證，並將用戶端的 SSL 憑證提供給請求此憑證的所有已部署應用程式。