Services

The runtime io.quarkus.scheduler.Scheduler exposes only trigger ids and next-fire times — neither of which the shared task contract carries — while the cron/every expressions and target method are known only at build time. So the Quarkus adapter captures every @Scheduled method from the application's Jandex index at build time (the same pattern as Architecture base-package and Vulnerabilities dependency capture). It maps each onto the same trigger/expression/initial-delay fields: a cron member becomes a CRON row, an every member a FIXED_RATE row (with the duration parsed to milliseconds), and a delay/delayed initial delay is carried through. The panel is available only when the quarkus-scheduler extension is present; programmatic Scheduler.newJob() jobs are not captured.

When BootUI is active it customizes every auto-configured RestClient and RestTemplate with a shared ClientHttpRequestInterceptor (Spring), or hooks every @RegisterRestClient proxy via the MicroProfile RestClientListener SPI (Quarkus). Both instrumentation points let the request through and only best-effort record around it, so an instrumentation error never breaks the call.

A per-method breakdown badges GET/POST/PUT/DELETE/other counts, and an "Instrumented clients" row lists which client types (RestClient, RestTemplate, WebClient, or Quarkus REST Client Reactive) are actually wired in. The panel groups calls by method, host, and normalized path — numeric and UUID segments collapse to {id}, so /orders/1 and /orders/2 group under /orders/{id}. It flags a group at or above bootui.rest-client-trace.chatty-call-threshold calls as a chatty (repeated-call) pattern. Unlike SQL's N+1 rule, which only flags repeated SELECTs, a chatty pattern is flagged for calls of any HTTP method, since looping a POST/PUT per item is just as costly as looping a GET. A flagged group also lists the distinct call site(s) that issued it, most-recently-seen first and bounded to a handful of entries. Each call row expands to reveal the full URI, request headers when that adapter supports them, client type, trace id, executing thread, call site, and error message. Rows filter by HTTP method, a slow-only toggle, or free text across URI, host, method, client, and thread.

• Spring retains the URI and masks query values by name (the same SecretMasker rules Config and HTTP Exchanges use, matched percent-decoded so a URL-encoded parameter name cannot slip through). URI authority credentials such as user:secret@host are removed before buffering, and the client error message is flattened, credential-redacted, and truncated — a transport exception routinely quotes the whole request URL. Request headers are withheld by default; bootui.rest-client-trace.capture-headers=true opts into bounded, exposure-aware header capture.
• Quarkus is deliberately stricter: always metadata-only, it ignores that header property, never reads or retains request/response bodies, arbitrary headers, authorization, cookies, credentials, or tokens, and strips URI user-info/fragments plus masks sensitive path/query values before storage.

bootui.rest-client-trace.capture-call-site defaults to true and only trades a small, defensively-bounded stack walk per call for the ability to see where a call came from. On Quarkus this attribution is best-effort, because a reactive client callback can run after the issuing stack has unwound.

On Spring, the customizer that wires a given client type fails open, skipping itself entirely when that client's Spring Boot module (for example spring-boot-webclient) is not on the classpath, so an app without WebClient simply never gets a WebClient customizer rather than failing startup. On WebFlux, WebClient calls are captured through an ExchangeFilterFunction installed by Spring Boot's auto-configured WebClient.Builder, and its reactive /stream endpoint provides the same pause/resume, clear, and live-refresh behavior without linking servlet classes.

On Quarkus the manifest is capability-driven because REST Client proxies are built lazily: when quarkus-rest-client is present the panel stays visible and reports that no proxy has been initialized until the first one is built, then its SSE stream refreshes on the first captured call. The QuarkusRestClientTraceListener (registered via ServiceProviderBuildItem when the capability is present) attaches a QuarkusRestClientTraceFilter on every proxy. The filter runs after application request filters and before application response filters, so it brackets the transport without replacing application customization. Quarkus reports a pre-response transport failure to the response filter with status 0; BootUI records that as a failed call with no invented HTTP status, while any real 4xx/5xx response remains a transport-successful error response. The same RestClientTraceRecorder backs both adapters, so the panel shape is identical.

Because the trace buffer is genuinely event-driven, the browser subscribes to /bootui/api/rest-client-trace/stream and the server pushes a small coalesced notification the moment a call is captured, the buffer is cleared, or recording is paused/resumed. The push carries no data — masking and truncation still apply through the regular endpoint — and bursts of calls are folded into a single refresh so high-volume workloads do not flood the UI. Recent calls surface in Live Activity using the same trace-id-first, serving-thread-second correlation SQL statements use. The "chatty" grouping above is not yet surfaced as a row-level badge in the merged stream the way SQL's N+1 suspicion is — it is visible only in this panel's own "Most frequent calls" table. Tracing, the initial recording state, header capture, call-site capture, buffer size, the slow-call and chatty-call thresholds, and URI/header truncation limits are all configurable under bootui.rest-client-trace.*.

• Resilience4j — read live from the CircuitBreakerRegistry, RetryRegistry, RateLimiterRegistry, BulkheadRegistry, ThreadPoolBulkheadRegistry, and TimeLimiterRegistry beans, including entries created lazily at runtime. Resilience4j's own event publishers feed the event feed, so state transitions and retries appear without any wrapping or proxying by BootUI.
• Spring Retry — @Retryable metadata plus an additive RetryListener bean that records retry attempts and exhaustion.
• SmallRye Fault Tolerance — @CircuitBreaker, @Retry, @Timeout, @Bulkhead, @RateLimit, and @Fallback annotations captured from the Jandex index at build time, with MicroProfile configuration overrides resolved at runtime and marked configured. This includes the MicroProfile enabled switches, so a policy disabled through configuration is listed with a leading enabled = false setting rather than shown as if it still applied. Live circuit breaker state and state-transition events come from CircuitBreakerMaintenance for breakers carrying @CircuitBreakerName; SmallRye publishes no per-call event stream, so retries and rejections are not individually captured.

Event capture is metadata only: policy name, outcome, attempt number, duration, the simple name of a failure's exception class, and circuit breaker state. Method arguments, return values, payloads, and exception messages are never recorded. Clicking a Live Activity FAULT_TOLERANCE entry opens this panel filtered to that policy.

Frame size comes from the transport's own getPayloadLength() (Spring) or from the length of an already-materialized byte[] on the messaging channel, and is simply omitted when neither is available, so no application message is ever consumed or copied. Raw provider session ids are never exposed — each is replaced by a salted, per-process, one-way hash, and destinations are redacted into the buffer, so Spring's resolved user destinations (/queue/x-user<simpSessionId>) surface as /queue/x-user{session} rather than leaking a live, addressable identifier. BootUI reads the endpoint registry Spring or Quarkus already built and the connections that already exist, and never opens, closes, probes, or writes to a connection. Local-only Pause/Resume (frame capture) and Clear (buffer and counters) actions are available where capture is supported, and both honor bootui.panels.websockets.read-only.

• On Spring MVC with @EnableWebSocketMessageBroker, BootUI registers a WebSocketHandlerDecoratorFactory plus inbound and outbound ChannelInterceptors through the public WebSocketMessageBrokerConfigurer contract, so STOMP endpoints report frameCaptureSupported=true and are badged installed. Native WebSocketHandler endpoints registered without the message broker report their full topology but are badged metadata, because decorating them would require reaching into non-public state.
• On Spring WebFlux and Quarkus, the panel reports endpoints and live connections but frameCaptureSupported=false with the concrete reason: @EnableWebSocketMessageBroker is servlet-only, and Quarkus WebSockets Next exposes no message-interception SPI.

Live session tracking is reported with the same honesty through sessionTrackingSupported and sessionTrackingUnavailableReason: Spring MVC and Quarkus observe connection lifecycle, while Spring WebFlux exposes no session registry, so its empty Sessions table says not supported on this stack instead of implying nothing is connected. Buffer sizes, initial capture state, and per-collection caps are configurable under bootui.websockets.*; every collection is independently truncated and the panel says when it was.

On Spring, the panel is gated on spring-websocket and spring-messaging being on the classpath. On Quarkus it is gated on quarkus-websockets-next being present and at least one @WebSocket endpoint being declared, with the endpoint topology captured at build time from the Jandex index and connection lifecycle observed through @Open/@Closed CDI events over OpenConnections. The SSE push carries no data — the regular endpoint still applies every masking, ordering, and truncation rule.

The BootUI starter captures local application spans automatically when telemetry is enabled, and cooperating local services can still send OTLP spans to the embedded receiver. As with the Traces panel, recent chats, model breakdowns, token-series windows, spans, and attributes are all bounded so large local runs stay responsive. When no framework is detected, the setup checklist shows two side-by-side guides — one for Spring AI and one for LangChain4j — explaining the dependency and configuration each needs to emit GenAI spans (including optional prompt/completion content capture). When both prerequisites are ready but no chat spans have arrived yet, the panel shows a ready empty state rather than setup guidance.

Prompt/response snippets appear only when the framework is configured to capture content. For Spring AI, set spring.ai.chat.client.observations.log-prompt, spring.ai.chat.observations.log-prompt, and spring.ai.chat.observations.log-completion. For LangChain4j, enable GenAI message-content capture on the OpenTelemetry instrumentation.

GenAI spans are captured when the application depends on quarkus-opentelemetry (for example alongside quarkus-langchain4j, or any OpenTelemetry GenAI instrumentation that emits the gen_ai.* semantic-convention spans). When no framework is detected, the setup checklist adapts to the platform: on Quarkus it shows a single LangChain4j guide using quarkus-langchain4j plus quarkus-opentelemetry and BootUI's in-process capture model — no embedded OTLP receiver — instead of the Spring AI / LangChain4j side-by-side guides.

A tier carries its level (L0 is consulted first), implementation type, locality (in this JVM or remote), configured maximum entry count, and configured expiry. When the provider's own configuration makes a bare number misleading, it also carries a short policy note — a weight-bounded Caffeine cache, for instance, states that its bound is a total weight rather than an entry count. Counters are shown as their own labelled series — provider statistics are never blended with Micrometer meters, and both are rendered side by side when both exist. A Micrometer series that has recorded no request yet shows ratio unknown, rather than a misleading 0%.

• A cache implementation that does not describe its storage reports no tiers at all and is marked Not described with a reason, rather than having a tier inferred from its class name.
• A counter a provider does not expose (Caffeine has no put or explicit-removal counter, for instance) is omitted, never rendered as zero.
• Statistics are reported as available only when the provider says it is recording. Caffeine without recordStats() and Spring Data Redis without enableStatistics() both report unavailable with the reason and the fix, instead of an all-zero series that reads like a cold cache.
• A hit ratio is derived only from a hit and a miss counter the adapter declared comparable (same counter family, scope, and window) and only when their sum is positive. An idle cache shows ratio unknown with the reason, never "0%".
• Reading tiers and counters never contacts anything over the network. No Redis entry count is reported, because counting keys would be an unsolicited network round trip on panel render. Local reads stay cheap too, with one honest exception: the Quarkus adapter reads a Caffeine cache's entry count through Quarkus' own keySet() accessor, which copies the key set, so a very large Quarkus cache pays a proportional local cost when opened. The Quarkus extension is dev/test-only and BootUI does not read entry counts anywhere else.
• Large topologies are bounded (100 managers, 500 caches per manager, 20 tiers per cache) and truncation is stated in the report's warnings rather than silently dropping rows.

A Caffeine cache built with recordStats() shows hits, misses, requests, evictions, load successes/failures, a hit ratio, and its configured maximum size and expiry. A RedisCache shows a remote tier with its configured time-to-live and, once spring.cache.redis.enable-statistics=true, the locally recorded gets/hits/misses/puts/deletes with the instant they have been accumulating from. A spring.cache.type=simple cache shows one local in-memory map tier and honestly reports that a plain map records nothing.

The same panel (kept under the shared id cache) is served over quarkus-cache, reading the live topology from the application's CacheManager and overlaying the same Micrometer metrics. Quarkus's public CaffeineCache interface exposes no statistics accessor, so hit/miss counters are reported unavailable and the panel points at Micrometer cache metrics instead. The panel is gated on the quarkus-cache extension (the CACHE capability).

How the topology, metrics, and clear action work

BootUI reads the live cache topology from the application's io.quarkus.cache.CacheManager, overlays the same Micrometer cache metrics (when a quarkus-micrometer registry is present and per-cache metrics are enabled), and the clear action evicts via cache.invalidateAll(). Tier metadata is reported the same way as on Spring: one local Caffeine tier per cache, with the maximum size and expiry configured under quarkus.cache.caffeine."<name>".*. Rather than reaching into Quarkus's internal CaffeineCacheImpl by reflection, the panel reports the hit and miss counters as unavailable with that reason. Because Quarkus binds caching with build-time annotations (@CacheResult, @CacheInvalidate, @CacheInvalidateAll) woven into methods, there is no runtime registry of cached operations, so the operations table is replaced by a short explanatory note and the panel shows cache names, metrics, and clear. The panel is reported unavailable, with a capability hint, on applications that do not use quarkus-cache.

Opening a message shows the parsed from/to/cc/bcc, an HTML preview rendered in a sandboxed iframe (scripts and same-origin access both disabled), the plain-text alternative, and attachment metadata (name/type/size, never contents). Email content is not treated as a config secret, so it is not masked by the global bootui.expose-values flag. Teams routing real customer PII through a shared dev environment can opt into masking with bootui.email.mask-content=true, which reuses the same name-based SecretMasker heuristic as Configuration/HTTP Exchanges and is only then lifted back under bootui.expose-values=FULL. The dev-trap mode is similar to MailDev/GreenMail. Each captured message's text/HTML body is truncated at bootui.email.max-body-length characters (default 200,000, matching EmailStore.DEFAULT_MAX_BODY_LENGTH) so a single oversized message cannot spike memory before the bootui.email.max-entries entry-count cap would evict it. Attachment content is never captured (metadata only), so this cap only applies to bodies.

The panel is identical on Quarkus over the same /bootui/api/email contract, available when quarkus-mailer is on the classpath. One behaviour differs by necessity: because Quarkus fires its capture event after the send, the recorded-but-not-sent distinction reflects Quarkus's own mock-mail mode (quarkus.mailer.mock=true, the default in dev and test) rather than a BootUI trap, and such messages are labelled mock instead of dev-trap.

Quarkus capture wiring and attachment sizes

The .eml bytes are produced by the shared engine renderer so they match Spring's. Quarkus's blocking/reactive/Mutiny Mailer beans all funnel through one internal mailer that fires a CDI SentMail event after every successful send, so a single @Observes SentMail observer captures every send style — the Quarkus analogue of Spring's CapturingJavaMailSender decorator. The panel is available when quarkus-mailer is on the classpath (and dark in production); otherwise it reports a clear unavailable reason. Attachment sizes are shown as unknown on Quarkus, since the sent-attachment API exposes none.

A produced record's offset isn't known at send time, and a producer send's duration is not exposed by either framework's callback. A Kafka payload is an arbitrary, potentially large and sensitive object with no generic masking strategy, so only metadata is retained. Capture is on by default whenever a Kafka integration is present and the panel is enabled, and is tuned through the same bootui.kafka.* properties Live Activity uses (enabled, capture-key, max-entries, max-key-length) — see docs/PROPERTIES.md. Turning off key capture (bootui.kafka.capture-key=false) is reflected with a notice instead of blank hashes, and turning off capture entirely (bootui.kafka.enabled=false) leaves already-captured messages visible with a similar notice.

Configured @Incoming/@Outgoing channels determine whether the panel receives any activity. Incoming deliveries carry connector metadata automatically; outgoing messages are captured only when they already carry OutgoingKafkaRecordMetadata, so a payload-only emission that relies entirely on channel configuration is not recorded. Without the extension the panel reports a clear unavailable reason.

On Spring, BootUI installs a MessagePostProcessor on every RabbitTemplate bean via the public addBeforePublishPostProcessors API and prepends a MethodInterceptor to every AbstractRabbitListenerContainerFactory's advice chain — composing with, not replacing, any existing post-processors or advice. On Quarkus, it hooks SmallRye Reactive Messaging's OutgoingInterceptor/IncomingInterceptor SPI, so the same recorder is fed from either framework. Spring publishes are captured at the supported before-publish hook and therefore represent a publish attempt; Quarkus publish ack/nack and both consumer paths represent terminal outcomes. The tuning properties are bootui.rabbitmq.enabled, bootui.rabbitmq.capture-correlation-id, bootui.rabbitmq.max-entries, and bootui.rabbitmq.max-correlation-id-length.

Incoming deliveries carry connector metadata automatically; outgoing messages are captured only when they already carry OutgoingRabbitMQMetadata, so a payload-only emission that relies entirely on channel configuration is not recorded. Without the extension the panel reports a clear unavailable reason.

Capture uses the same JmsActivityRecorder as Live Activity, so both surfaces stay synchronized and clearing the panel also clears retained JMS entries from the merged feed. bootui.jms.enabled, bootui.jms.capture-message-id, bootui.jms.max-entries, and bootui.jms.max-message-id-length configure both surfaces. The Spring interception uses runtime class proxies, so the JMS panel reports unavailable in a GraalVM native image rather than claiming capture is active when those proxies cannot be generated.