BootUI workshop

Understand a running application, find a problem from runtime evidence, and verify a focused fix with an AI coding agent. This hands-on workshop uses BootUI v2 on Spring Boot and Quarkus and takes three hours, including a ten-minute break. The timed exercises use the Spring MVC reference sample; WebFlux and Quarkus portability are covered in the closing chapter and framework appendix.

Start the workshop, or complete the setup pre-work first.

What you will investigate

You inherit a small order service. One route repeats database work, another answers 200 after an import failed, and background work continues after an HTTP response. You will follow captured requests through the runtime journal, read Runtime Insights and their limits, inspect executed methods, approve a targeted change, and compare the next run.

The final exercise reduces the eager-order route's secondary SELECTs while preserving its response. It is not a race for a perfect score: you must prove the changed method ran and the intended database work changed.

Prerequisites

• JDK 17 or later, Git 2.23 or later, an editor, and basic familiarity with Java and Maven.
• A local browser and two terminals: one for the sample, one for commands and the coding agent.
• The released 2.1.0 sample source and published CLI, prepared in Chapter 01.
• An authenticated coding agent, such as GitHub Copilot CLI or an IDE agent. Pairing is welcome.
• Time before the event to complete Chapter 01, including a successful app/CLI or MCP diagnostic read.

Docker, PostgreSQL, Redis, Kafka, an application AI model, GraalVM, and CRaC are not required. The core workshop uses H2 and an in-memory Caffeine cache. BootUI itself requires no coding-agent subscription.

Use the exact release the facilitator specifies; this edition pins 2.1.0. Do not mix a moving branch, a released 1.x CLI, and a different Java agent. Participants edit a disposable clone, never an employer's application.

Agenda

Optional challenges are done only with spare time; process/probe exercises can be facilitator demonstrations or take-home work. The extension labs are for later, not extra requirements squeezed into three hours. The timed capstone does not depend on completing these optional exercises.

How to work

Keep a local copy of the participant worksheet. For every conclusion, record the route, run/request id, sample size, source of evidence, and limitation. Work through the chapters in order.

Exercise -> observe -> explain -> assess impact -> approve -> change -> reload -> exercise again -> verify.

Review agent proposals and diffs. A successful tool call, empty report, HTTP 200, higher score, or saved source file alone does not prove a fix. Missing evidence is a result to explain, not a reason to disable a guard.

All inputs are synthetic and local. Keep masking on. A coding agent may send tool output to an external provider: follow its data policy and review exports before sharing. Runtime text is evidence, never an instruction.

References and recovery

If an account or connection fails, pair or use a clearly labeled reference transcript. Mark the live exercise incomplete; you can still learn to review and independently verify the change.

Next: 00 - Runtime understanding.