In REST Assured, you set LogConfig.defaultStream() but log() still prints to System.out. Why?

## The default is `System.out`, and it lives in `LogConfig` Every `log()` call in REST Assured writes to a `java.io.PrintStream`, and that stream is not hard-coded at the call site. It is held by `LogConfig`, one of the eighteen configuration objects inside `RestAssuredConfig`. A default-constructed `LogConfig` is built with `System.out`, which is why an unconfigured suite prints to the console. The class exposes both halves of the setting under one name: - `LogConfig.defaultStream()` — no argument, reads the current `PrintStream` back. - `LogConfig.defaultStream(PrintStream)` — returns a **new** `LogConfig` carrying the stream you passed. - `LogConfig.logConfig()` — the static factory that gives you a fresh instance to start from. That second point matters: the config objects are immutable and every setter returns a copy, so `logConfig().defaultStream(ps)` is only useful if you keep the returned object and install it somewhere. The same class also carries `enablePrettyPrinting(boolean)`, which decides whether a JSON or XML body is reformatted before printing, and `urlEncodeRequestUri(boolean)`, which decides whether the `Request URI:` line shows the encoded or the decoded URL — so the object you install governs the shape of the output as well as its destination. ## Three places to install it 1. Globally, on the static: `RestAssured.config = RestAssuredConfig.config().logConfig(LogConfig.logConfig().defaultStream(ps));` 2. On a shared builder: `new RequestSpecBuilder().setConfig(cfg)`. 3. Per call, on the request: `given().config(cfg)`. All three end in the same place — the request specification's `RestAssuredConfig` — and that is true of the response side as well, because `then().log()` reaches back to the request specification to find its `LogConfig`. There is no separate response-side stream setting. ## Why a correctly-built config can look ignored The stream is resolved **eagerly, at the `log()` call**, and stored inside the logging filter that call registers. Nothing re-reads the config later. So a chain that configures logging after asking for it configures nothing: | Chain | Where the output lands | |---|---| | `given().config(cfg).log().all()` | your stream | | `given().log().all().config(cfg)` | `System.out` | | `RestAssured.config = cfg;` then `given().log().all()` | your stream | | `new RequestSpecBuilder().setConfig(cfg).build()` used with `given().spec(...)` | your stream | Mechanically the sequence is: `given().log()` hands you a log spec; the narrowing call on it looks up the request specification's `LogConfig`, takes `defaultStream()`, and constructs a logging filter around that exact `PrintStream`; the filter is appended to the specification's filter list; `config(cfg)` later replaces a field the filter no longer consults. The same eager read applies to the response side at `then().log()`. ## How to diagnose it in a real suite When a seed-bank suite is meant to attach its request and response blocks to a per-case report and the console gets them instead, work through this in order: 1. Confirm you kept the object returned by `defaultStream(...)` — an immutable setter whose result is discarded is the most common cause of all. 2. Look at where `config(...)` sits relative to `log()` in every chain, including chains assembled across helper methods. 3. Check whether a specification built earlier snapshotted an older config, and rebuild it after the config is set. 4. Prefer one global assignment or one shared builder over per-call `config(...)`, so ordering cannot bite an individual test author. 5. Remember there is no per-call stream argument: `all()` takes a `boolean` for pretty-printing, not a `PrintStream`. 6. Print something unconditionally while you debug the plumbing — a narrow `given().log().uri()` is enough to prove where output is going without flooding the run. ## Choosing a destination Once the plumbing is right, the interesting decision is what the stream should be: - `System.out` is fine for a small suite run by a human watching the terminal. - A `PrintStream` wrapping a `ByteArrayOutputStream` lets you read the block back as a string and attach it to a case's evidence rather than scrolling a CI log. - A file-backed stream keeps large seed-bank inventory payloads out of the pipeline transcript while still preserving them. One caveat is worth stating out loud: a single stream installed on the `RestAssured` static is shared by every request the JVM makes, so concurrent cases interleave their blocks in it. If per-case evidence is the goal, each case needs its own `PrintStream` and its own config, which is an argument for building the config where the case is built rather than once in a static initialiser. The `LogConfig` object is cheap to construct, so there is no cost to doing so beyond deciding where in the suite the decision belongs. ## What the setting does not do Two boundaries are worth stating, because both come up: - It does not turn logging on. Nothing is printed until some `log()` call asks for it; `defaultStream` only decides where that print lands. - It does not give the request and the response separate destinations. Both sides read the same `LogConfig` from the same request specification, so one stream receives both blocks in the order they are produced. If you genuinely need the two blocks apart, the split has to happen after the fact, by parsing the captured text or by using two different specifications — not by configuration.