A JMeter run with -Jenv.host=prod.internal -q staging.properties still hits staging. Why?

The command line is applied left to right, and nothing about a flag's identity gives it priority. That single rule explains the whole surprise. ## One pass, in order After loading the base file, `JMeter.initializeProperties` does this: ```java List<CLOption> clOptions = parser.getArguments(); for (CLOption option : clOptions) { switch (option.getDescriptor().getId()) { case PROPFILE2_OPT -> { ... jmeterProps.putAll(tmp); } // -q case JMETER_PROPERTY -> { ... jmeterProps.setProperty(name, value); } // -J ... } } ``` `CLArgsParser.getArguments()` returns the options in the order the parser added them, which is the order you typed them. `-q`, `-S`, `-D`, `-J`, `-G` and `-L` are all handled in that one pass. So two options that touch the same key resolve by **position**, not by kind. In the failing command, `-Jenv.host=prod.internal` runs first and calls `setProperty`. Then `-q staging.properties` runs and calls `putAll`, and because that file also defines `env.host`, the map entry is overwritten. The plan resolves `env.host` to the staging value and the run goes where you did not intend. ## The fix is positional Put the override to the right of the file it overrides: ``` jmeter -n -t checkout.jmx -l run.jtl \ -q ./config/staging.properties \ -Jenv.host=prod.api.internal ``` Now the file supplies the environment's stable values and the flag lands on top of them. This is the ordering you almost always want, and it is worth making a house rule: **files first, flags last.** It reads the way people expect it to read, and it means a one-off override on the command line always wins. ## Confirming it from the log You do not have to reason about this from the shell history. Every step is recorded, in the order it happened: ``` INFO o.a.j.JMeter: Setting JMeter property: env.host=prod.api.internal INFO o.a.j.JMeter: Loading additional properties from: ./config/staging.properties ``` Reading those two lines top to bottom tells you which write happened last. If the `Loading additional properties from:` line sits below a `Setting JMeter property:` line for a key that file also defines, you have found your answer. ## Related traps in the same loop - **`-q` is repeatable, so several files can shadow each other**, again by position. A common file followed by an environment file behaves as you would hope; the reverse does not. - **`-D` and `-J` cannot lose an ordering race to each other.** They write to different stores, and a `-J` entry simply shadows a system property of the same name, so the conflict is always within one store. - **An empty value on a later `-J` deletes an earlier definition.** `-Jenv.host=staging.internal ... -Jenv.host=` leaves the property unset, logging `Removing JMeter property: env.host`. - **`-p` is not part of this loop at all.** It is handled before the loop starts, so its position on the command line is irrelevant; anything the loop applies necessarily comes after it. ## Why this bites the staging-to-production case specifically The pattern that produces it is exactly the one this leaf exists for: a plan parameterised from outside, a checked-in file per environment, and a pipeline that appends "just one override" to a command line it inherited. The override is appended in the wrong place, the run looks healthy, the results file is full, and every sample went to the wrong host. Nothing fails; the numbers are simply about the wrong system. Behaviour described is Apache JMeter 6.0.0.