JSF 1.1 升級 1.2 遷移指南：五大坑與解決方案

升級背景

專案需求驅動從 JSF 1.1 升級 1.2，過程暴露多項不相容變更，記錄如下供參考。

坑 1：包級私有建構子導致 Bean 實例化失敗

現象：1.1 正常的 Backing Bean 在 1.2 拋出實例化異常。
原因：1.1 使用反射呼叫非 public 建構子，1.2 改為要求 public 無參建構子。
解決：將所有受管 Bean 建構子改為 public。

坑 2：SelectOneMenu 驗證機制變更破壞 AJAX 動態選單

現象：客戶端 AJAX 動態修改選項（如多級聯動）後，所有 Command 組件動作失效。
原因：1.2 Render 階段新增嚴格驗證——提交值必須在初始化選項範圍內，否則直接短路生命週期，跳過 Invoke Application。
解決：自訂 SelectOneMenu 繼承並覆寫驗證邏輯，或使用 PrimeFaces/RichFaces 等支援 AJAX 的組件庫。

坑 3：組件 ID 自動生成演算法變更

現象：大量 JavaScript 直接使用自動生成的 ID（如 form:table:3:link），升級後全掛。
原因：1.2 修改 ID 生成演算法，且新增「開關」控制是否自動生成。
解決：強制指定所有組件 id 屬性，絕不依賴自動生成。

坑 4：Spring 整合變簡單

好消息：1.2 RI 內建支援 Spring VariableResolver，無需第三方 jsf-spring.jar，直接在 faces-config.xml 設定：

<application>
  <variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

坑 5：Tomahawk 組件庫版本不相容

現象：MyFaces Core 1.2 釋出，但 Tomahawk 停留 1.1，導致上傳/下載組件無法使用。
對策：等待 Tomahawk 1.2、改用 RichFaces/PrimeFaces 對應組件、或自行回溯修復。

總結建議

1. 升級前完整自動化測試覆蓋
2. 所有組件強制指定 id
3. Bean 建構子 public
4. 評估組件庫相容性，考慮遷移至現代組件庫
5. 善用 1.2 新特性：統一 EL、註解支援、PhaseListener 增強