JBoss EAP 02：WAR、EAR 與 Spring Boot，從檔案走到可呼叫的 API

orders.war 已經上傳，瀏覽器卻回 404。此時「部署成功」太模糊：檔案存在、部署已啟用、Web context 已建立、請求打到正確路徑，是四件要各自確認的事。先把檔案如何變成服務畫出來，才知道應該查哪一層。

包裝先決定邊界

WAR 裡常見 WEB-INF/classes 與 WEB-INF/lib；EAR 可以包含 WAR、EJB 模組與共用 lib。它們的類別可見性不同，不能把所有 jar 搬到同一層就期待行為相同。RAR 是連接器，不是把 MQ client jar 改名後的結果。

Spring Boot 放進 EAP 時，啟動責任會改變

上一個系列用 java -jar 啟動內嵌容器；外部容器部署則需要真正的 WAR 建置、SpringBootServletInitializer 與適當的容器依賴 scope。下列是啟動橋接的局部示意，省略 import 與 Maven 設定，不能單獨當成完整部署範例。

@SpringBootApplication
public class OrdersApplication extends SpringBootServletInitializer {
    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
        return builder.sources(OrdersApplication.class);
    }
}

把內嵌 Tomcat 標為 provided 是 Boot 官方 WAR 路徑的一部分，卻還沒有回答 EAP 的 logging、JPA、JTA 與模組由誰提供。先列出提供者，再依目標版本文件調整。Boot 能產出 WAR，也不等於某組 EAP update、Boot 與第三方套件已獲廠商支援；WebFlux 應用也不能套用這條傳統 WAR 教學。

把產物、部署與網址串起來

# Read a local artifact you already built.
jar tf orders.war
shasum -a 256 orders.war

# Separately, in an authorized standalone training CLI:
deployment info

保留產物 hash，避免兩個都叫 orders.war 的檔案被當成同一版。接著記錄部署名稱、runtime-name、enabled、status 與啟動 log，再確認實際 context root。檔名可以影響預設路徑，但描述檔與部署設定可能改變它；不能只猜 /orders。代理前綴、Web context 與 Controller mapping 也要分層寫下。

Client URL → proxy route → EAP listener
           → web context → Spring mapping → business method

Example only: /public/orders/api/42
Actual prefix and context must be observed.

練習：狀態 OK，HTTP 卻是 404

在工作表先寫出「已知：管理介面顯示部署 OK；未知：實際 context、代理轉送與 mapping」。答案不是立即重打包。先用同一個 request ID 對照代理與應用 log，確認請求是否進入正確實例，再查 context 與路由。打到健康檢查只證明那個端點有回應；最後仍要跑訂單案例，核對 body、狀態碼與資料副作用。