Desktop, Daemon and Container

## The switch names a lifetime, not an interface The most common mistake here is reading `-cmd` as "headless" and `-daemon` as "the other one". Both are headless. In `CommandLine.parseSwitchs`, `-cmd` does `setDaemon(false); setGUI(false)` and `-daemon` does `setDaemon(true); setGUI(false)`. The only field that differs is the daemon flag, and that flag decides **how long the process lives**, not whether a window appears. If you supply neither switch, the GUI flag stays on and you get the windowed session. If you supply both, the `CommandLine` constructor throws an `IllegalArgumentException` saying the two "cannot be used at the same time", `ZAP.main` catches it, prints an invalid-parameter message, and exits without starting anything. ## Three bootstraps, one decision `ZAP.createZapBootstrap` reads the parsed arguments and chooses one of three classes, stamping a `ZAP.ProcessType` as it goes: | invocation | bootstrap | `ProcessType` | window | local listener | what `start()` returns | |---|---|---|---|---|---| | no switch | `GuiBootstrap` | `desktop` | yes | yes | zero, immediately — the UI runs on the AWT queue | | `-cmd` | `CommandLineBootstrap` | `cmdline` | no | yes | `control.getExitStatus()` after shutdown | | `-daemon` | `DaemonBootstrap` | `daemon` | no | yes | zero, immediately — a background thread keeps going | The enum carries a fourth value, `zaas`, that this selection never assigns. The two headless bootstraps share `HeadlessBootstrap`, which initialises the control singleton without a view; that shared base is why so much of the behaviour is identical. ## What the one-shot path does differently - It runs `control.runCommandLine()` **on the calling thread**, so the call blocks until the registered work is finished. - It shuts the program down in a `finally` block and then returns `control.getExitStatus()`, which becomes the process exit code. - It owns the terminal argument paths — help, version and support-info printing all end the run right there. - `CommandLine.info(...)` and `CommandLine.error(...)`, the methods command-line listeners are told to report through, **only write to standard output or standard error when the process type is `cmdline`**. Everywhere else they write to the log and nothing else. - The network add-on skips the *additional* configured listeners in this mode; only the main one is started. ## What the service path does differently - It calls `View.setDaemon(true)`, which the source comments as preventing the view from ever being initialised. - It moves the whole sequence — control init, session handling, the command-line hook, `runCommandLine()` — onto a thread it names `ZAP-daemon`, and `start()` returns zero as soon as that thread is running. - It runs an update check that the one-shot path skips — the windowed session runs the same check, so this is a one-shot omission rather than a daemon speciality. - After the work finishes, the thread sleeps in a loop rather than returning. The source comment says this is the only non-daemon thread, so it is what keeps the JVM alive, and that shutting down is something the control API does with an explicit exit. ## Both of them start the listener The local server that carries the control API and the proxy on the same port is brought up by the `network` add-on's command-line handling, which both headless modes reach because both hook command-line listeners. So "I need `-daemon` before anything will listen" is false. What `-daemon` gives you is **time**: the listener is still there after the registered work has finished, which is the whole point of running the program as a service. ## What the switch does not change Almost everything else is shared, and saying so is half of answering the question well: - **Which add-ons load.** That is decided by the build and the install directory, not by the lifetime flag. A one-shot run is not a reduced program. - **Session handling.** `-session` and `-newsession` are processed by the shared headless base, the same way in both modes, and supplying that pair together is rejected just as the lifetime pair is. - **Configuration overrides.** `-config key=value` goes through the same control-overrides object either way. - **The command-line hook.** Both modes call the extension loader's command-line hook, which is how every add-on-registered argument — including the plan flags — reaches its listener at all. So when someone says a flag "only works in daemon mode", be suspicious: usually what they mean is that the *process was still alive* long enough for them to use it. ## Why it matters in a pipeline A job that wants a verdict wants the one-shot lifetime, because that is the lifetime that has somewhere to put an answer. A job that wants to drive the program interactively over its control API — several steps, its own ordering, its own polling — wants the service lifetime, and must then decide separately how the pipeline learns whether the run passed. Choosing the wrong one usually shows up as a job that hangs forever (a service where a one-shot was wanted) or as a job whose steps all race a process that already exited.