Repository navigation
Lucee throws error accessing this.env in config/app.cfm for new applications #2325
Description
Describe the bug
When running a newly created Wheels application on Lucee, an error is thrown indicating that this.env is not accessible within config/app.cfm.
The application fails with the following error:
Component [Application] has no accessible Member with name [ENV]
Detail: enable [trigger data member] in administrator to also invoke getters and setters
This occurs when attempting to access environment variables using this.env inside config/app.cfm.
Stacktrace (relevant part):
C:\inetpub\wwwroot\wheels\config\app.cfm: line 37
if (structKeyExists(this.env, "WHEELS_ENV") && this.env.WHEELS_ENV == "development"){
To Reproduce
Steps to reproduce the behavior:
- Create a Wheels application and configure
.envand.env.developmentfiles with the datasource and environment variables. - Start the application and open it in a browser.
- Observe the error related to
this.env.
*Code Sample
config/app.cfm):
<cfscript>
this.name = "demoapp";
if (structKeyExists(this.env, "WHEELS_ENV") && this.env.WHEELS_ENV == "development"){
this.datasources[this.env.DS_NAME] = {
class: "com.mysql.cj.jdbc.Driver",
connectionString: "jdbc:mysql://#this.env.DS_HOST#:#this.env.DS_PORT#/#this.env.DB_DATABASE#?serverTimezone=UTC",
username: "#this.env.DB_USER#",
password: "#this.env.DB_PASSWORD#"
};
}
</cfscript>
Environment Variables:
.env
WHEELS_ENV=development
WHEELS_CI=true
BASE_URL=http://127.0.0.1:8080
.env.development
WHEELS_ENV=development
DS_NAME=demoapp
DS_HOST=localhost
DS_PORT=3306
DS_DATABASE=demoapp
DS_USER=root
DS_PASSWORD=root
Expected behavior
Environment variables defined in .env files should be accessible via this.env inside config/app.cfm without requiring additional Lucee administrator configuration.
Actual behavior
Lucee throws an error indicating that this.env is not accessible, preventing the application from starting.
Possible cause
The issue appears to be caused by the execution order in Application.cfc, where config/app.cfm is included before the environment variables (this.env) are initialized.
Specifically:
- The following block was recently introduced and runs early in the application lifecycle:
if (FileExists(expandPath("../config/app.cfm"))) {
include "../config/app.cfm";
}
- At this point, this.env has not yet been created or populated, since the environment-loading logic executes later in the file.
- As a result, when
config/app.cfmtries to accessthis.env, Lucee throws:
Component [Application] has no accessible Member with name [ENV]
Screenshots
Desktop:
- OS: Any
Additional context
config/app.cfmis included again later (after this.env is initialized), which suggests that the earlier inclusion is redundant and occurs prematurely.- In previous behavior,
config/app.cfmwas only executed after environment setup, so this.env was always available.
Activity
bpamiri commentedon Apr 28, 2026
I tried to reproduce on macOS arm64 + Lucee 7.0.0.395 with the latest
develop(post-#2348). The pattern from your repro:…runs cleanly here — no
Component [Application] has no accessible Member with name [ENV]error. Looking at the framework'scli/lucli/templates/app/public/Application.cfc:49-85,this.envis initialized in the pseudo-constructor beforeinclude "../config/app.cfm"runs at line 89, so the access ought to be safe.A few questions to narrow the gap so we can patch it properly:
wheels infoor/wheels/inforeports it. The error wording (enable [trigger data member]) is a Lucee 5/6 era message; Lucee 7 reports differently. Knowing your exact Lucee version would help.this.envsetup block was added relatively recently; older framework copies may not have it.C:\inetpub\wwwroot\wheels\Application.cfcmatch the template exactly, or have local edits? If it's a custom one without the lines 49–85 setup block,this.envwould never be initialized.wheels newor a different command? Olderwheels init/initpaths produced different Application.cfc layouts.Happy to dig deeper once we have those — easiest path is probably to add a defensive guard at the top of
config/app.cfmso user code is robust regardless of framework lifecycle.zainforbjs commentedon Apr 29, 2026
Thanks for digging into this.
I think I’ve identified why we’re seeing different behavior.
I created the application using the
wheels newCLI command, and it generated anApplication.cfcbased on:public/Application.cfc(lines 36–38)In this version,
config/app.cfmis included early:At this point,
this.envhas not yet been initialized, which leads to:However, the file you referenced:
cli/lucli/templates/app/public/Application.cfc(lines 49–85)initializes
this.envbefore includingconfig/app.cfm, so the same code works correctly there.So it looks like the CLI is currently scaffolding the app using a different (or outdated)
Application.cfccompared to the template you tested against.That mismatch seems to be the root cause of the issue on my side.
fix(config): remove premature config/app.cfm include so this.env is a…