Why does ${signingKey} inside a JMeter JSR223 element's Script File reach Groovy unresolved?

## Two sources of code, two different rules Every JSR223 element can get its code from one of two places, and only one of them is a JMeter property: - **Script** (the inline text area) is stored as `<stringProp name="script">` in the plan. Like any other element property, it is passed through JMeter's variable and function replacement before the value reaches the bean, so `${signingKey}` and `${__UUID()}` are already text by the time the engine is handed the source. - **Script File** is stored as `<stringProp name="filename">`. That *path* is a property and is substituted; the **contents of the file are not**. JMeter opens the file with a plain reader and gives it to the engine directly. So `${signingKey}` inside a `.groovy` file is exactly what the engine receives. Nothing in JMeter ever looks at it. ## What Groovy makes of it The manual's phrasing is *"likely to cause a syntax error"*, and how true that is depends on where you wrote it: 1. Outside a string — `def key = ${signingKey}` — Groovy still compiles it: `$` is a legal identifier, so the parser reads a call to a method named `$` with a closure argument. It fails at run time instead, with `groovy.lang.MissingMethodException: No signature of method: $`, which surfaces as a `ScriptException`. Because the text compiles, Tools > Compile JSR223 Test Elements passes it. 2. Inside a double-quoted string — `def key = "${signingKey}"` — the text is valid Groovy, but it is now *Groovy's* interpolation, resolved against Groovy's own scope. There is no local or bound variable of that name, so it fails at run time too, with a `MissingPropertyException` naming it. 3. Inside a single-quoted string — `def key = '${signingKey}'` — it is a plain literal and your signature is computed from the literal placeholder text itself. This is the nastiest of the three, because nothing fails. Case 3 is why this bug survives review: a run that signs every request with the literal string `${signingKey}` produces requests and results, just wrong ones. ## The fix Do not put JMeter syntax in a script file. Read the value at run time from the objects JMeter binds into the script's scope — the bound-context objects are their own topic, but the shape is `vars.get("signingKey")` for a variable and `props.get("signing.key")` for a property. The `Parameters` field of the element is the other supported channel: it *is* a property, so `${...}` in it is substituted, and the resulting text reaches the script as a binding. That gives you a script file that is constant text — which is also exactly what the compilation cache wants, since a file is keyed on its path and last-modified time rather than on its content. ## Why the split exists at all Substitution happens when JMeter prepares an element's properties for use. A file's contents are never an element property, so there is no point at which JMeter could substitute into them without reading and rewriting the file on every execution. Keeping files verbatim is what makes them safely compilable once and reusable. ## Symptoms to recognise - A `ScriptException` wrapping `groovy.lang.MissingMethodException: No signature of method: $` at the line where the `${...}` appears — case 1. Note the GUI's Compile JSR223 Test Elements check passes this, because the text compiles. - A `MissingPropertyException` or a null value for something you thought JMeter would fill in — case 2. - A request that is well-formed but always carries the same literal placeholder text where a real value should be — case 3. All three go away the moment the file stops containing `${}` at all, which is the rule worth writing down: **`${}` is plan syntax, not script syntax.**