JBoss EAP 06: diagnose the right layer and verify migration parity

A migration can produce many errors at once. Treating each line as an independent problem creates unnecessary work. Find the first attributable failure and its cause chain, identify the responsible layer, and check whether later unavailable services are consequences.

Classify before choosing the next observation

Management login does not establish application-user authentication. Spring Security and EAP security may act at different stages. Use correlation identifiers and a time window to narrow logs. Review sensitive data before sharing: the XML inventory is not a general anonymization tool.

From 6.4 to 8.1: inventory, then separate changes

This move crosses JDK, enterprise APIs, Spring, Hibernate, MQ, and build tooling. Inventory WARs, EARs, MDBs, and standalone batches separately, with entry points, providers, resources, and baseline cases. Do not overwrite a new installation with old XML. Check removed or changed subsystems and the source-version scope of each migration instruction.

Reduce each verification step to a module or responsibility, such as packaging and loading before data access. This is a work-planning method, not a claim that every intermediate combination is supported for production. Check the target matrix and applicable migration steps separately.

One case, four evidence surfaces

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

Establish equivalent isolated data and test queues rather than replaying into production. Compare HTTP status, headers, and body; relevant DB changes; message contents, destinations, counts, and completion; and required log events and errors. Timestamps, generated IDs, or updated wording may differ. Define justified normalization rules in advance and retain raw evidence.

Asynchronous work needs an explicit completion condition, observation window, and timeout. Missing MQ evidence is incomplete, or a failure under predefined criteria, rather than success after a short sleep. Include rollback, redelivery, duplicate inputs, and recovery alongside happy paths.

Exercise: HTTP 200, correct DB, missing MQ evidence

Can this pass migration acceptance? Not when messaging belongs to the contract. Mark the evidence gap and inspect publication, transaction completion, destination, and consumption. The workbook provides those fields. Complete one normal and one failing case to produce an explainable result beyond a successful build.