Logging & Identifying Logs per User

With -Dswingbridge.consoleLogPrefix=true, SwingBridge wraps System.out and System.err. Every line written by an application-instance thread is prefixed with [swing:<runId>]; server output passes through unchanged. This catches, regardless of the logging framework the Swing application uses:

The flag is off by default because replacing the process streams is observable behavior; enabling it is a deliberate deployment decision.

When you also opt in to per-line user names (see Showing the Name on Every Line), the prefix carries the user as well, for example [swing:7f3k2a|alice].

File appenders write straight to disk — they never pass through the console streams, so the prefix above can’t reach them. For those, SwingBridge ships logging-framework adapters (inside swing-bridge-flow; no extra dependency). They’re passive: nothing changes until your pattern references a token.

Log4j2 — the common case, since swing-bridge-flow itself brings Log4j2. Add the token to any pattern:

%X{swingSession} is filled in automatically: SwingBridge registers a Log4j2 ContextDataProvider that captures the run ID at the logging call site, on the calling thread. Because the value travels with the log event, it stays correct even with async appenders, where the actual formatting happens on a background thread. Server lines render an empty value.

Alternatively, %swingSession (a pattern converter, discovered automatically) renders the same ID with an explicit - for server lines.

To include the user’s name, add the parallel %X{swingUser} (or %swingUser) token and turn on per-line user names. Without that flag the token renders empty (or -), so it’s safe to leave in a shared pattern:

Logback — the adapter classes ship with swing-bridge-flow and activate when Logback is your backend. Register them in logback.xml:

The turbo filter stamps the run ID (and, when per-line user names are on, the user) into the Mapped Diagnostic Context (MDC) at the call site — required for correctness with AsyncAppender — after which plain %X{swingSession} and %X{swingUser} work, too. Drop the swingUser rule and token if you only want the run ID.

java.util.logging — configure the prefixing formatter on a handler:

The formatter prefixes each record with [swing:<runId>], and with per-line user names on it becomes [swing:<runId>|<user>] — there’s no separate token to add.

Because the run ID (and user) become normal context fields, they flow into JSON layouts and log aggregation systems such as Elastic, Loki, and Splunk as regular attributes: finding everything for run 7f3k2a, or everything for alice, becomes a filter instead of a text search.

By default, only the run ID is repeated on each line and the user’s name lives in the correlation line. To repeat the name on every line as well, start the server with:

Once an identity has been published, console prefixes then read [swing:7f3k2a|alice], and the %swingUser / %X{swingUser} tokens (see Log Files and Structured Logs) render the name. Lines logged before login — or on any session with no identity yet — stay [swing:7f3k2a].

In many migrations, the Swing application keeps its own login dialog, and the Vaadin side has no security context yet. The identity is born inside Swing, so it’s published from there. Three options, ordered by how much you can change the Swing code — the first is a one-liner and needs no new dependency.

Option 1 — one line, no new dependency. In the Swing application, after a successful login, on any thread the application owns (the Event Dispatch Thread is fine):

This is plain JDK API — the Swing project gains no dependency on SwingBridge and behaves identically as a desktop application (where the property is simply unused). SwingBridge routes the value per session, so concurrent users can’t overwrite each other, and logs a correlation line the moment it’s set. This is the recommended starting point.

Option 2 — the log context API (more capabilities). If the Swing project already depends on swing-bridge-annotations (or accepts it — a small JAR with zero transitive dependencies), the SwingBridgeLogContext facade offers more than the property, and every method is desktop-safe:

Standalone on a desktop, the reads return null, setUser() does nothing, and reportIncident() falls back to System.err — the same JAR works in both worlds. One packaging note: unlike the pure annotations, these are real code references, so the desktop distribution ships the annotations JAR as well.

Option 3 — zero Swing changes. When the Swing JAR can’t be modified at all, the Vaadin application observes the Swing application’s own session state reflectively and attaches the identity once login completes:

Two rules make this safe: only read existing state — never call factory methods such as getInstance(), whose constructors may have side effects (server connections, file writes) — and stop polling when the view detaches.

The other common shape: authentication and navigation have been modernized into the Vaadin application (for example, with Spring Security), and Vaadin menus open views that each embed a Swing application. Here the identity is born on the server side, so it flows the other way. In each Vaadin view that embeds a Swing application:

Timing is flexible — before adding the bridge to the view or any time later; a correlation line is logged either way. The identity is keyed per (server session, Swing application) pair, which matters when Vaadin handles navigation: views embedding different Swing applications each call setLogIdentity() for their own bridge (typically factored into a base view class), while two views embedding the same application in one session share an instance, so one call covers both. Each opened application gets its own run ID, and all correlation lines carry the same session and user — support can search by application instance (run ID) or by everything the user did (session ID).

The Swing application needs nothing in this setup — but SwingBridgeLogContext.runId() and reportIncident() remain fully useful, and userName() returns whatever the Vaadin side attached, so the Swing application can display the logged-in user without owning authentication.

Some Swing applications route everything through a homegrown logging subsystem that needs the identity before first use. Two directions, depending on where the identity lives:

Pulling from the Swing side — the application asks SwingBridge for the values whenever its subsystem initializes:

Pushing from the Vaadin side — when the identity is host-side and the subsystem must be initialized proactively, use the typed interop APIs: annotate a method in the Swing application and call it from the Vaadin view as soon as the application is ready.

In the Swing application:

In the Vaadin view, through the generated bridge:

The onReady callback guarantees the call runs once the application is initialized, before the user interacts with it. See Interop APIs for setting up the annotation processing and generated bridges.

Setting the identity from both sides is allowed and occasionally useful — for example, Vaadin attaches the single-sign-on principal when the view opens, and the Swing application later refines it after a role or mandate selection. The last write wins for that application instance, and each write logs its own correlation line, so the log history shows the transition rather than losing it. A null or blank value removes the identity.

The Swing application’s JARs are loaded by a class loader that delegates to the server’s classpath first. Consequences:

The practical upshot: tag the server’s appender patterns (see above), and every framework generation inside the Swing application is covered.

In the rare setup where the server deliberately excludes Log4j2 and the Swing application runs its own logging context, the adapters still work — reference them from the application’s configuration file instead, or add the forwarding appender to stream its events into the server log, attributed:

In own-context setups, also give each session its own log file path (for example, include the run ID in the file pattern) — many sessions rolling one shared file is a corruption risk regardless of attribution.

SLF4J is a facade: at startup it picks one provider (binding) that decides where all SLF4J log statements go. Two pitfalls in SwingBridge deployments:

Spring Boot defaults to Logback, SwingBridge brings Log4j2. Running both backends splits your logs in two. The Installation from Scratch template resolves the clash in Logback’s favor: it excludes log4j-slf4j2-impl from swing-bridge-flow, so SLF4J traffic (Spring, SwingBridge itself) goes to Logback. That setup works with the Logback adapters — with one caveat: a Swing application calling Log4j APIs directly still logs through Log4j2’s own default configuration, which writes to the console only (prefixed, but absent from your Logback-managed files).

To get everything — Spring, SwingBridge, and every Swing application — into one set of tagged appenders, standardize on Log4j2 instead: keep swing-bridge-flow’s binding (remove the template’s exclusion), and exclude Logback in the Vaadin application’s `pom.xml:

and configure Log4j2 via log4j2-spring.xml on the classpath.

Multiple providers on the classpath. SLF4J warns (Class path contains multiple SLF4J providers) and then silently picks one — not necessarily the one you want. Notably, Vaadin’s development tooling ships a shaded JAR embedding slf4j-simple, which can win the auto-selection: the symptom is that SLF4J-routed lines (Spring, SwingBridge’s own correlation lines) never reach your Log4j2 appenders, while direct Log4j calls from the Swing application do. The fix is one JVM property that pins the provider explicitly:

One structural limit applies everywhere: output produced on shared JVM threads that don’t belong to any application instance — for example, ForkJoinPool.commonPool() — can’t be attributed to a user.