I’m spinning up a server with the env variable LUCEE_INSPECT_TEMPLATE set to “never”, but the templates are being inspected. It doesn’t seem like any setting I set is being picked up.
Very simple repro case here: GitHub - mjclemente/test_inspect_template_error_repro: Error repro for Lucee 6.2.1+77 and LUCEE_INSPECT_TEMPLATE env
One strange thing I noticed is that when I dump the ENV, I get the expected value “never” - but when I output it as a string, it is displayed as “nevertrue”. The repro shows this behavior as well.
Don’t forget to tell us about your stack!
OS : MacOs Sequoia (15.3.2)
Java Version : AdoptOpenJDK 11.0.11+9
Lucee Version : 6.2.1+77
related: Jira
that true is quite the WFT? must be some debug or something, let me check
UPDATE: ignore my initial response! took me a second,
writeOutput()
returns a success Boolean, i.e. true, but you don’t need it here!
<cfoutput>#writeoutput(server.system.environment.LUCEE_INSPECT_TEMPLATE)#</cfoutput>
should just be
<cfoutput>#server.system.environment.LUCEE_INSPECT_TEMPLATE#</cfoutput>
here’s the bytecode
public final Object call(PageContext var1) throws Throwable {
var1.outputStart();
try {
var1.write("\r\n ");
var1.write(Caster.toString(Now.call(var1)));
var1.write("<br>\r\n LUCEE_INSPECT_TEMPLATE env is set to: ");
var1.write(Caster.toString(Caster.toRef(WriteOutput.call(var1, Caster.toString(var1.get(var1.getCollection(var1.serverScope().get(KeyConstants._SYSTEM), KeyConstants._ENVIRONMENT), keys[0]))))));
var1.write("zzz<br>\r\n LUCEE_INSPECT_TEMPLATE env is set to: ");
var1.write(Caster.toString(Caster.toRef(WriteOutput.call(var1, Caster.toString(var1.get(var1.getCollection(var1.serverScope().get(KeyConstants._SYSTEM), KeyConstants._ENVIRONMENT), keys[0]))))));
var1.write("<br>\r\n\r\n ");
var1.write(Caster.toString(var1.get(var1.getCollection(var1.serverScope().get(KeyConstants._SYSTEM), KeyConstants._ENVIRONMENT), keys[0])));
var1.write("<br>\r\n ");
var1.write(Caster.toString(CFFunction.call(var1, new Object[]{FunctionValueImpl.newInstance(KeyConstants.___filename, "dump.cfm"), FunctionValueImpl.newInstance(KeyConstants.___name, "dump"), FunctionValueImpl.newInstance(KeyConstants.___isweb, Boolean.FALSE), FunctionValueImpl.newInstance(KeyConstants.___mapping, "/mapping-function"), FunctionValueImpl.newInstance(KeyConstants._var, var1.get(var1.getCollection(var1.serverScope().get(KeyConstants._SYSTEM), KeyConstants._ENVIRONMENT), keys[0])), FunctionValueImpl.newInstance(KeyConstants._label, "LUCEE_INSPECT_TEMPLATE")})));
var1.write("\r\n ");
} finally {
var1.outputEnd();
}
return null;
}
I think the return true from WriteOutput is being written out here?
public final class WriteOutput extends BIF {
public static boolean call(PageContext pc, String string) throws PageException {
try {
pc.forceWrite(string);
}
catch (IOException e) {
throw Caster.toPageException(e);
}
return true;
}
public static boolean call(PageContext pc, String string, String encodeFor) throws PageException {
try {
if (!StringUtil.isEmpty(string)) pc.forceWrite(ESAPIUtil.esapiEncode(pc, encodeFor, string));
else pc.forceWrite(string);
}
catch (IOException e) {
throw Caster.toPageException(e);
}
@mjclemente please file a bug, @micstriit this is a fun one!
Hahaha - I wasn’t as concerned with the writeoutput, as the LUCEE_INSPECT_TEMPLATE not getting picked up.
The ENV is set to never inspect the templates, but they are being inspected.
See the comment here
https://luceeserver.atlassian.net/browse/LDEV-5407
Hmmm, this is different to previous versions?
It’s not really useful as it stands is it, except when deploying fresh? Otherwise the CFConfig.json
already exists and will be ignored
Ahh - yes - that’s definitely it.
Our use case is using docker-compose
to set LUCEE_INSPECT_TEMPLATE=never and docker-compose-override
to set LUCEE_INSPECT_TEMPLATE=always.
Basically, an easy way to handle performance for production and never having to deal with the template cache while developing.
Would there be a better approach for this? I guess we could use the environment variable within CFConfig.json
, right?
With the comment on that ticket, is the intention that all env vars won’t override the .CFConfig.json? What about LUCEE_EXTENSIONS, for example? Our base image has the .CFConfig.json, but each app gets the extensions they need through the .env var LUCEE_EXTENSIONS and that seems to work ok.
Don’t worry, LUCEE_EXTENSIONS is working as expected.
Over on Lucee-testlab, I have some hardcore integration tests, which helped us really nail down the behaviour of extension install and upgrading
name: Check Bad .CFConfigs
on:
workflow_dispatch:
workflow_call:
jobs:
tests:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
luceeVersion:
[
5.4/snapshot/jar,
6.0/snapshot/jar,
6.1/snapshot/jar,
6.1.0/snapshot/jar,
6.2/snapshot/jar,
]
This file has been truncated. show original
Which was part of our sprint, .CFConfig.json should be a pleasure to work with
https://luceeserver.atlassian.net/browse/LDEV-4984
So even with docker-compose, running up a fresh container, LUCEE_INSPECT_TEMPLATE isn’t working?
Those set to inherit, should be respecting the following setting, which is expected to be override by the env var right?
this demonstrates the problem
So, I’m speculating that our issue is that the docker image get warmed up when we build it, so the CFConfig.json
sets inspectTemplate: auto
. Then, when we use the warmed up image, the value is set, so the ENV doesn’t override it for development or production.
Using "inspectTemplate": "{env:LUCEE_INSPECT_TEMPLATE}"
in our CFConfig.json
gets us the desired result. That’s good enough for us.
I really like that approach!
One of the things @micstriit has been working on is removing defaults from .CFconfig.json which keeps things simpler
Zackster
Split this topic
March 23, 2025, 4:59pm
11
A post was split to a new topic: Settings admin password