JBoss EAP 06：從錯誤訊息找到責任層，再驗證升級前後行為不變

升級後的 log 一次出現很多錯誤，最花腦力的做法是把每一行都當成獨立問題。先找第一個可定位的失敗與完整 cause chain，再問是哪一層無法完成責任。後面那些「服務未啟動」可能只是連帶結果。

先分類，再選下一個觀察

管理帳號能登入 CLI，不等於應用使用者通過認證；Spring Security 與 EAP 的安全設定也可能位於不同階段。記錄 request／業務關聯 ID 與時間範圍，縮小 log，不必每次重讀整份檔案。分享證據前另外檢查個資與憑證；教材的 XML 工具不是通用去識別化工具。

6.4 到 8.1：先盤點，再拆開變更

這次同時跨 JDK、Java EE／Jakarta EE、Spring、Hibernate、MQ 與建置方式。先把 WAR、EAR、MDB、獨立批次分開列，每個都記入口、提供者、資源與基準案例。舊 XML 不宜直接覆蓋新安裝；依 Red Hat 遷移文件核對已移除或變更的 subsystem、security 與設定。文件的適用來源版本要逐段看，不能把某一段遷移指令套到全部 6.4 資產。

可以把一次驗證的變更縮到一個模組或一種責任，例如先確認打包與類別載入，再處理資料存取。這是安排工作的方法，不表示每個中間組合都能在正式環境受支援地執行。目標平台的版本矩陣與必要遷移步驟仍需另行核對。

同一個案例，留下四種證據

Case: ORDER-FAIL-02 (synthetic planning example)
Input: fixed payload + business key
Baseline: isolated old-system data and queue state
Target: equivalent isolated new-system state
Observe: HTTP + DB + MQ + correlated logs
Completion: explicit asynchronous completion condition + timeout
Result: match / mismatch / missing evidence

先在隔離資料與測試 queue 建立相同起點，不直接重播到正式環境。HTTP 比狀態碼、header 與 body；DB 比相關資料與交易效果；MQ 比業務內容、目的地、次數與完成狀態；log 比必要事件、錯誤與關聯。log 的時間戳、隨機 ID 或新版訊息格式不一定逐字相同，哪些可以正規化，要先寫理由與規則，並保留原始證據。

非同步處理不能只 sleep 幾秒就判成功。先定義完成條件、觀察窗口與逾時；沒有看到 MQ 結果，應標為證據缺漏或依已定義條件判失敗。回滾、重送、重複輸入與故障復原案例，也要和正常路徑一起排進驗收。

練習：HTTP 200、DB 正確，MQ 沒證據

這能勾選升級通過嗎？不能；若 MQ 是契約的一部分，先標「待補證據」，接著查訊息產生、交易提交、目的地與消費路徑。下載包的 WORKBOOK 已留好欄位。先完成一個正常案例與一個失敗案例，你就有可以向同事解釋的結果，而不只是「AI 改完、build 有過」。