Second question (it's actually more than one question, now that I've finished typing it...) on how static properties are handled. My expectation is that the "class" that a static property is a property of is unique to the JVM. So if I have a CFC at /path/to/My.cfc, and it has a static property, then all code running on that entire JVM would be using the same path.to.My class? I am seeing two different requests on not only the same JVM but running in the same Lucee instance having two different versions of the same "class". If I update the static property in one (eg:

My::someVar = "new value"

, I do not see the change in the other request. I am seeing another variant where I access

My::someVar

for reading (eg:

someOtherVar = My::someVar

, Lucee says "nup,

someVar

doesn't exist. Yet I run another request that has

writeOutput(My::someVar)

, and that outputs its value. If these were objects I'd check their hashcodes expecting them to be different objects cos I've done something daft and accidentally created two objects. But there's no equivalent daftery I can perform with static properties. And also I have no idea how I might get some sort of hashcode or ID from a CFC name anyhow. Is there a way of identifying which

My

my code is using, to check if somehow I have two of them? NB: there are not different mappings in play here, all references are via the file-system path from the Lucee web root.

java.lang.System.identityHashCode

against

My::someVar

might be something If this in a test, curious if the test runner is being helpful by (re)writing sourcefiles on a per it-block basis (for coverage or mocking or whatever), so there really is a separate instance per test

Good call. I would have wondered about that had there been a SUT involved at all. In this case it's an acceptance test, and other than going

Thing::woo = testValue

, the actual test is just observing an HTTP req, the handling of which also uses

Thing::woo

The test works fine, sometimes. And it's not like "it's not actually exercising the code sometimes so seems to be OK", I have proven the code as written runs fine. There is some combination of restarting Lucee, running the application, source code files being touched (and I specifically mean touched, not meaningfully changed), and running the test that seems to alter whether or not a) the static variable is even defined; b) changing its value is respected. This is without changing any of the code around the variable assignment itself. The only thing that I haven't analysed is that this is all in a CFWheels app, and CFWheels is... erm... well its understanding of how code should be implemented is "wayward" at best. However I don't think even the vagaries (cough) of the CFWheels "way" ought to be able to interfere with how static initialiser blocks are executed.