How do you start WireMock's standalone jar on a chosen port with your own stub directory?
answer
- one jar, two flags
- a directory, not a file
- the default root is where you stand
- mappings/ and __files/ live under it
- --port and --root-dir do the work
basics
~20 sRun java -jar wiremock-standalone.jar with --port for the listening port and --root-dir for the directory holding mappings and __files. Without --root-dir the server roots itself in the current working directory. --verbose prints what the server is doing to stdout.
solid answer
~50 sThe standalone distribution is a shaded uber-jar, so `java -jar wiremock-standalone.jar --port 8089 --root-dir ./scaffolding-inspection-stubs` is the whole command — there is nothing else to place on the classpath. `--port` sets the HTTP port the server listens on, and `--root-dir` names the directory beneath which WireMock expects `mappings/` and `__files/`; leave `--root-dir` out and it uses the current working directory instead. Two flags make the first run readable: `--verbose` turns on verbose logging to stdout, and `--disable-banner` removes the start-up logo from a build log. The server then answers `GET /v1/scaffolds/SC-4471/inspections` from whatever mapping in `mappings/` matches it, and returns 404 when none does. Point the code under test at `http://localhost:8089` rather than the real scaffolding-inspection host, and check one known path before suspecting a mapping: a 404 means the request arrived and nothing answered it.
go deeper
Be able to type the command from memory: java -jar wiremock-standalone.jar with --port and --root-dir, and know that mappings/ and __files/ live directly beneath the root you name.
Explain why the flag is so often omitted — the default root is the working directory — and what that default costs the moment the process starts somewhere other than your checkout.
Show the check you run before blaming a stub: status line first, because a 404 and a connection failure send you to entirely different files.
Decide as a matter of policy whether teams launch stub servers from a jar, from the image or embedded, and make the choice consistent so a stub set is portable between all three.
## The command, and why it is that short ```bash java -jar wiremock-standalone.jar --port 8089 --root-dir ./scaffolding-inspection-stubs --verbose ``` WireMock's standalone distribution is a **shaded uber-jar**: its dependencies are packaged inside it, so a bare `java -jar` runs the server with nothing else on the classpath. That is the whole appeal of the standalone shape — a stub server for a scaffolding-inspection API becomes a process anybody can start, on a laptop, on a build agent, or as the command a container runs. ## What `--root-dir` means `--root-dir` names **one directory**, and WireMock expects a fixed layout beneath it: - `mappings/` — the JSON stub definitions. Each file describes a request to match and the reply to send. - `__files/` — the body files a definition can serve by name, such as a stored `scaffold-SC-4471-inspections.json` payload. When you do not pass `--root-dir`, the root is the process's current working directory. That default is the reason the flag feels optional: developers run the jar from inside the checkout that already has the two directories, so it works without being asked for. The moment the process starts somewhere else — a build agent's workspace, a container — the default stops being right, and the flag becomes the only thing standing between you and an empty stub set. ## The flags worth knowing on day one - `--port` — the HTTP port the server listens on. Choose one your suite already knows, and point the code under test at it rather than at the real scaffolding-inspection host. - `--root-dir` — the directory holding `mappings/` and `__files/`. - `--verbose` — verbose logging to stdout. On a first run this is the difference between *the stub is wrong* and *the server never saw the request*. - `--disable-banner` — suppresses the start-up logo, which is welcome noise reduction in a CI log. - `--load-resources-from-classpath` — the alternative to `--root-dir` when the stub set is packaged inside a jar on the classpath rather than sitting on disk. - `--permitted-system-keys` — restricts which environment variables and system properties a response template may read, which matters once a stub server is more than a local toy. ## What `--root-dir` does not do It does not name the `mappings` directory itself. Point it at `./scaffolding-inspection-stubs/mappings` and WireMock will look for `./scaffolding-inspection-stubs/mappings/mappings`, find nothing, and answer 404 to everything. It also does not change how a request is matched, what a mapping may contain, or when the files are read — the read happens as the process starts. ## Checking it worked before blaming a stub 1. Start the process and watch stdout. With `--verbose` the server tells you what it is doing rather than sitting silent. 2. Call one path you know a mapping answers — `curl -si http://localhost:8089/v1/scaffolds/SC-4471/inspections` — and look at the status line first. 3. A 404 means the request arrived and nothing answered it: either the set is empty because the root was wrong, or a mapping exists and did not match. 4. A connection failure means the request never arrived: wrong port, wrong host, or the process is not running. That ordering matters more than it looks. The two failures feel the same from a test's point of view — the assertion fails — but they live in different files, and half of all time lost to a stub server is spent editing the wrong one. ## Where this fits The standalone jar is one of three shapes the same server takes: started as a process from the command line, run from the published container image, or embedded in a JVM by the test itself. The command line is the one to learn first, because the container image runs exactly this launcher with a root directory already chosen, and the flags you learn here are the arguments you pass a container later. - Local exploration: `java -jar` from the checkout, no flags, default root. - Reproducible run: `java -jar` with an explicit `--port` and `--root-dir`, so nothing depends on where you happened to be standing. - Shared or CI use: the same launcher, invoked by the image, with the root fixed by the image instead of by you. Learn the second form and the third costs nothing.
- What happens if you omit --root-dir entirely?WireMock roots itself in the process's current working directory and looks for `mappings/` and `__files/` there. From a checkout that already has them it works and the flag never comes up; from anywhere else the server starts normally with an empty stub set and answers 404 to everything. The failure is silent, which is why an explicit `--root-dir` is worth writing even when the default would have worked.
- Why is there nothing to add to the classpath when running the standalone jar?Because `wiremock-standalone` is a shaded uber-jar: the dependencies it needs are packaged inside it, so `java -jar` alone is enough to start the server. That is what makes it convenient as a process or as a container's command, and it is also why adding your own jar alongside it needs a classpath-based launch rather than a bare `-jar`.
Think of --root-dir as a static web server's document root: WireMock does not care where you launched it from, only what it finds under that one directory.
saying these in an interview costs you the question
- Pointing --root-dir at the mappings directory instead of its parent
- Assuming stub files are found wherever they sit in the repository
- Thinking extra jars are needed on the classpath to start standalone
- Editing a mapping to fix what is really a wrong-port connection failure
- Believing --port changes anything about how requests are matched