JBoss EAPJakarta EEJava 21企業系統升級

JBoss EAP 02: WAR, EAR, and the path to a working API

··2 min read
Back to the JBoss EAP learning path

An uploaded orders.war still returns 404. “Deployed” hides several states: content exists, deployment is enabled, a web context started, and the request reached the correct route. Trace those stages before changing code.

Packaging defines boundaries

FormatTypical contentsOwner
WARWeb classes, WEB-INF/lib, descriptorsEAP web container and application framework
EAREnterprise modules and shared librariesEAP enterprise deployment
RARAdapter connecting an external systemEAP resource-adapters subsystem
Executable Boot JARApplication and executable launch layoutIts own JVM launch process
Extensions describe different roles; renaming does not convert them.

A WAR commonly contains WEB-INF/classes and WEB-INF/lib. An EAR can contain WARs, EJB modules, and shared libraries with different visibility rules. Moving all JARs to one directory does not preserve those rules. An adapter is not a renamed MQ client JAR.

Boot inside EAP changes startup ownership

The Boot series launched an embedded server with java -jar. External deployment requires WAR packaging, SpringBootServletInitializer, and appropriate container dependency scopes. This excerpt illustrates the startup bridge; imports and build configuration are omitted, so it is not a complete deployment sample.

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

Marking embedded Tomcat as provided is part of Boot’s documented WAR workflow. EAP logging, persistence, transaction, and module ownership still need decisions. Producing a WAR does not certify a vendor-supported combination. This traditional WAR route does not apply to WebFlux applications.

Connect artifact, deployment, and URL

text
# 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

Keep the artifact hash so identically named WARs are not mistaken for the same build. Record deployment and runtime names, enablement, status, and startup logs, then find the actual context root. Descriptors or configuration may override naming defaults. Separate proxy prefix, web context, and controller mapping.

text
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.

Exercise: OK status, HTTP 404

Record what is known—management reports OK—and what remains unknown: context, proxy forwarding, and mapping. Do not start by repackaging. Correlate the request across proxy and application logs, then inspect context and routing. A health endpoint responding does not establish order behavior; verify response and side effects with an order case.

Download the EAP offline kit: inventory, exercises, workbookNext: 03: Modules and JakartaLesson 08: build and inspect a Spring Boot WAR

Sources