BEA 的名字與應用服務器是同義詞。北美幾乎所有運行在 Unix 操作系統上的應用程序都運行在 Bea Weblogic Server 平臺上，特別是那些金融方面的應用。當前穩定的 WebLogic 8.1 版本要比較早的版本功能更多。向新版本遷移從來都具有挑戰性和冒險性，但是這樣做可以提高效率和增加新的功能，也有助于繼續使用當前供應商的產品和支持。
在 WebLogic 6.1平臺上開發的大多數應用程序都使用 JDK 1.3 或更早版本的 JDK。從 WebLogic 6.1 轉移到 WebLogic 8.1 意味著使應用程序與 JDK 1.4.1 或更高的版本兼容，這是因為在WebLogic 8.1 發布時，配套的是JDK 1.4。所有大多數遷移風險在BEA網站bea.com上已討論。這里我將給出一些個人觀點。
這些將是我們討論的要點。
從6.1向8.1的遷移，當前應用程序場境
遷移的常見問題
getter 方法和setter 方法
可序列化對象
WL cache
調整 JVM（Java 虛擬機）內存使用
帶有語言屬性的頁指令
Java.net.SocketException：打開文件太多
其他問題
從6.1向8.1的遷移——當前應用程序場境
我們的應用程序將要遷移到 WebLogic 8.1。當前的環境是：
操作系統：Solaris 5.8 P4
WebLogic Server 8.1P2
Java Release 1.4.2_06
Actuate 7.1SP6
主流的關系數據庫系統，對遷移沒有影響
Struts1.1 Framework
Model II Web Architecture
遷移的常見問題
從WebLogic 6.1向WebLogic 8.1遷移的常見問題包括：類路徑、系統路徑、環境變量、數據源、部署、JSP 解析、安全性、服務器配置以及 XML 解析。所有這些內容都在www.bea.com作了詳細討論。
例如，我們拿 XML 解析來說。WebLogic 8.1不像WebLogic 6.1 及早期的版本，它不能容忍編碼錯誤。因此，需要將編碼標準從 Unicode 改成 utf-16。
同時，不再需要 JSP 重編譯。因此，如下代碼必須要從 web.xml 中刪除掉：
<servlet>
<servlet-name>JSPClassServlet</servlet-name>
<servlet-class>WebLogic.servlet.JSPClassServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JSPClassServlet</servlet-name>
<url-pattern>*.JSP</url-pattern>
</servlet-mapping>
getter 方法和setter 方法
在 WebLogic 8.1 平臺上運行的應用程序使用了 JDK 1.4 或者更早的版本。因此，當我們從 WebLogic 6.1遷移到 WebLogic 8.1 時，我們顯然是遷移到了 JDK 1.4.1 或更晚的版本。JDK 更晚的版本遵守更嚴格的 Java 規范，這就意味著原來在較早版本的 JDK 下運行得很好的不合適代碼將在 JDK 1.4.1 或更晚的版本中導致錯誤。
例如，使用標簽庫就會有一個錯誤：
uri=′/WEB-INF/tlds/taglib.tld′ prefix=′j2ee′：對于´Items’屬性來說，沒有用于 Tag 類的 setter 方法。´com.sun.j2ee.apps.application.taglib.list. SearchListTag’可能會發生，因為在 /template.JSP 第八行有一個錯誤：<%@ taglib uri="/WEB-INF/tlds/taglib.tld" prefix="j2ee" %>
這種失敗發生在那些受Introspector API 支配的 JSP 和 bean 中。一個好的例子是getter 方法和 setter 方法。如果 setter 是一個整型，那么 getter 也必須是整型，而不能是字符串型。
可序列化對象
為了支持在內存中拷貝HTTP 會話，所有對象數據都必須是可序列化的。否則，會話復制就會失敗。當啟用了“debugging（調試）”時， WebLogic 輸出了一條警告信息，表明會話還沒有復制：
“Failed to replicate non-serializable object（復制不可序列化對象失敗）”
如果發生了這類事情，請查找拋出該錯誤的頁面，并且要確保所有置于會話中的數據都是可序列化的。每個存儲在會話中的對象必須實現一個可序列化的接口用于復制。
WL 緩存
這種 cache 必須始終從每個節點上刪除，用于 WebLogic 提取任何使用腳本修正過的代碼。（通常情況下，在一個生產環境中有多個節點用于意外、容錯和負載均衡。）WebLogic 8.1 服務器高速緩存標簽具有如下屬性：超時（timeout）、作用域（scope）、鍵（key）、異步（asyns）、名稱（name）、大小（size）和刷新（flush）。當把 flush 設定為 true 時，緩存就被刷新了。下面是一個簡單的 cache 標簽：
<wl:cache>
<!--the content between these tags will only be
refreshed on server restart-->
</wl:cache>
使用cache 標簽迫使每次新值計算時，已緩存過的值都要釋放掉。 cache必須以名稱屬性來命名。size 屬性將會清理所有值，而 key 屬性將會清理特定值。WebLogic 8.1 有兩個版本的cache，這樣就給我們提供了一種選擇，即使用軟引用（soft reference）來緩存，以避免系統內存的過度使用。然而，當 WebLogic 運行在 Hotspot VM 上時，我們是不能使用軟引用的。
調整 JVM（Java 虛擬機）內存使用
如果新環境的 JVM 堆大小是有限的，那么必須重新分解文件。如果我們在一個 JSP 頁面上合并了太多的內容，那么就可能導致 JVM 內存問題。我們都知道，JSP 作為一個單獨方法被編譯到servlet 上。如果有更多的標簽，那么 servlet 方法就會因為太大而不能被 JVM 理解。在那種情況下，用戶將會看到一個錯誤信息，即“Illegal target of jump or branch（非法的跳躍目標或分支）。”這就意味著 JSP 已經超過了大小限制，因此需要將它們重新分解。
有一種解決方案是，如果需要更多的內存來運行這些文件的話，提高JVM堆的大小值。提高堆的大小會降低延遲，增加穩定性。因此，在binTogether.bat 文件中的 JVM 選項一行，將 -Xms64m 改成 -Xms256m（或者更高）。
另一種解決方案是，將一個較大的頁面分解成很多較小的頁面。然后在運行時，通過include 將它們放在一起。使用<%@include> 不會起作用，因為它是一個編譯時的包含。
最后，還有個方法是，尋找保存這些標簽的地方。例如，有這樣一個標簽<html:option>，它是擴展用于顯示文本信息的，可以將以下代碼：
<Html:option ... ><bean:message key="foo"/></html:option>
替換為：
<html:option ... key="foo"/>
這類例子越多，情況就會越好。除了<html:option> 之外，其他一些struts 標簽是包含文本信息的捷徑。如果可以提前構建一個適當的集合，就會考慮將<html:option> 序列替換為 <html:options> 。
一種方案是使用我們自己的標簽。通過繼承BodyTagSupport 來修改一些頻繁使用的標簽以便擴展標簽支持，并且在 .tld 文件中使用 <body content>empty</body content> 來標志它們將會極大地降低生成的代碼大小。它可能不會每次都能起作用，但是它確實有所幫助。
只要 JSP 很大時，就需要將com.sun.tools.javac.main.largebranch 變量設為 true。
在那種情況下，必須使用JRocket，它捆綁在 WebLogic 8.1 上。它比 JDK 能更好地處理內存。
帶有語言屬性的頁面指令
在某些JSP代碼中，屬性語言的值要多次指定。這在WebLogic 6.1上是有效的，然而在向WebLogic 8.1遷移的代碼中，我們只要對這些值指定一次，否則的話就會按照J2EE規范的要求拋出一個JSPException 異常。
Java.net.SocketException：太多打開的文件
在轉換到 WebLogic 8.1 之后，服務器就會停止運行，并發送如下消息。它也許跟遷移無關，但是必須解決這個問題。
<Critical> <WebLogicServer> <BEA-000204>
<Failed to listen on port 7001, failure count: 1, failing for 0 seconds,
java.net.Socke tException: Too many open files>
應該立即采取的措施是在/etc/system 中將rlim_fd_max 的值提高為8192。但是這樣可能導致使用數上升至7000，因而它不是可行的解決方案。
最好的策略是，在操作系統中調整好TCP參數。
Java.lang.OutOfMemoryError
該錯誤就是一個運行時異常（Runtime Exception），它試圖在 WLS 8.1 SP3 中使用Sybase Pool 來執行一個存儲過程（procedure）。這個錯誤發生在我們使用 WebLogic 8.1 SP3 的時候。BEA 意識到了這個問題，并在 WebLogic 8.1SP4 中已經將它解決。對于那些想要使用8.1SP3 的人來說，BEA 正在通過 JAR 文件的方式提供一個補丁。
其他問題
a) 帶有語言屬性的頁面指令
在某些文件中的JSP代碼中，屬性語言值要多次指定。這在WebLogic 6.1上有效，然后遷移到WebLogic 8.1之后，我們就必須確保這些值的指定次數只能是一次，否則就會根據J2EE規范拋出一個JSPException 異常。
b) 在分級模式下部署應用程序
WebLogic 8.1 可以讓應用程序在多種模式下部署，這要視情況而定。在部署單一服務器時，域總是使用no_stage 模式。
c) 定義上下文root
我們的應用程序是孤立的，因此需要將如下代碼片斷加入到web.xml文件中。
<context-root>isoft/iSoft</context-root>
結束語
在所有應用程序中，不管應用服務器的手冊如何規定，代碼都必須強制遵循J2EE規范。
