WildFly & JBoss application servers
Understand Java runtime, application deployment, management, and dependencies.
GUIDE3 published lessons · Updated 2026-09-14
Before you begin
Use a disposable local WildFly installation and the JDK required by that WildFly release. WildFly and supported JBoss EAP releases are related but not interchangeable products. Follow the matching installation guide. Keep management access local to the lab.
Working toward: Deploy a small Java application and diagnose startup, dependency, and connectivity failures.
Read each explanation, work through the example, and attempt the exercise before opening its answer. Published lessons are ready to study; unfinished roadmap topics remain planned.
Validation: Based on upstream documentation. Platform-specific labs require the learner’s matching environment and are not execution-tested here.
1. Separate the runtime from the application
The JDK supplies Java tooling and the JVM. WildFly is an application server running on Java. A deployed application can fail even when the server starts successfully. Check compatibility in the selected release documentation.
java -version
# From your WildFly installation on Linux/macOS:
./bin/standalone.shWhat to expect
Java version output, followed by server startup logs if the JDK and configuration are compatible. Ctrl+C stops this foreground lab server.
Your turn
A server boots but the application reports a missing class. Which layers need checking?
Show answer and reasoning
Inspect the deployment error, application packaging and server/module dependencies. A healthy JVM does not guarantee a complete application artifact.Watch for: Do not choose a JDK merely because it is the newest; use the supported version matrix.
Link to this lesson2. Read the management model
The management CLI addresses resources and operations. A read-attribute operation observes state without changing configuration. Run the CLI in a second local terminal while the lab server is running.
./bin/jboss-cli.sh --connect
:read-attribute(name=server-state)
:read-children-names(child-type=deployment)What to expect
A management response containing server state and deployed application names. An empty deployment list is valid for a fresh server.
Your turn
Why distinguish server-state from deployment health?
Show answer and reasoning
The server can be running while a deployment is failed or its database dependency is unavailable. Inspect the specific deployment and logs next.Watch for: Do not expose the management interface publicly to make a local connection easier.
Link to this lesson3. Trace a dependency failure
A datasource connects the application server to a database. Failure can arise from DNS, routing, port policy, TLS, credentials, driver compatibility or the connection pool. A restart does not identify which layer failed.
What to expect
A short incident record with the exact exception, timestamp, affected deployment and dependency.
Your turn
The log says connection refused to the database address. What does changing a SQL query accomplish?
Show answer and reasoning
Usually nothing. First verify the resolved address, intended port and database listener, then network policy. A query cannot run before the connection exists.Watch for: Logs can contain credentials or personal data. Keep the lab fixture synthetic and redact incident extracts.
Link to this lessonPath to advanced
In-progress stages identify the lessons already published. All other listed topics remain planned. Each addition needs teaching, a reproducible lab, failure cases, and a checkpoint before the capstone.
Deploy
JDK compatibility, application archives, configuration and repeatable deployments.
PLANNEDConnect
Datasources, drivers, connection pools, transactions and credentials.
PLANNEDOperate
Management roles, TLS, metrics, logging, patching and rollback rehearsals.
PLANNED
References
Original AUWEN lessons, with upstream documentation for further study and version checks.
All learning paths and update notes →