wheels new scaffolds Application.cfc with missing application.wheelsdi assignment in onApplicationStart

[bpamiri]

Description

The Application.cfc generated by wheels new declares a local injector variable in onApplicationStart() but then attempts to use application.wheelsdi — which is never assigned. Since application.wheelsdi is the public 4.0 DI container (replacing the 3.x application.wirebox), the local variable should be assigned to it.

Reproduction

wheels new test-app --datasource=test --reload-password=PLACEHOLDER
cat test-app/public/Application.cfc

The generated onApplicationStart():

function onApplicationStart() {
    application.env = duplicate(this.env);
    injector = new wheels.Injector("wheels.Bindings");

    /* wheels/global object */
    application.wo = injector.getInstance("global");
    initArgs.path="wheels";
    initArgs.filename="onapplicationstart";
    application.wheelsdi.getInstance(name = "wheels.events.onapplicationstart", initArguments = initArgs).$init(this);
}

application.wheelsdi is never assigned. On first request, the last line throws because the application-scoped reference is undefined.

Impact

Every new application scaffolded by wheels new fails to boot until the user manually patches Application.cfc. Since this is also a framework boilerplate file that applications shouldn't customize, that's an uncomfortable workaround.

Suggested Fix

Assign the injector to application.wheelsdi so it matches the documented 4.0 DI container name and is available throughout the application:

function onApplicationStart() {
    application.env = duplicate(this.env);
    application.wheelsdi = new wheels.Injector("wheels.Bindings");

    /* wheels/global object */
    application.wo = application.wheelsdi.getInstance("global");
    initArgs.path="wheels";
    initArgs.filename="onapplicationstart";
    application.wheelsdi.getInstance(name = "wheels.events.onapplicationstart", initArguments = initArgs).$init(this);
}

This is consistent with the 4.0 migration path (application.wirebox → application.wheelsdi) documented in the 4.0 release audit.

Environment

• Wheels CLI: 4.0.0 (stable, brew install wheels)
• Scaffold command: wheels new <name> --datasource=<ds> --reload-password=<pw>

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report is reproducible by inspection: cli/lucli/templates/app/public/Application.cfc:93 declares a local injector variable, line 96 uses it once (application.wo = injector.getInstance("global")), and line 99 then references application.wheelsdi which is never assigned. The same pattern repeats inside onError() at lines 263-264. Every freshly scaffolded app inherits both copies.

Suspected layer

cli — see .ai/wheels/cli/ for scaffold/generator patterns. The defect is in the scaffold template, not in the DI container itself (vendor/wheels/Injector.cfc is fine).

Fix sketch

Patch cli/lucli/templates/app/public/Application.cfc so the injector is assigned to application.wheelsdi (the documented 4.0 container name) instead of a local var, and update the two adjacent injector.getInstance("global") reads to use application.wheelsdi.getInstance("global"). Both onApplicationStart() (lines 93-99) and onError() (lines 263-264) need the same change. Confirm whether the derived copies under examples/tweet/public/Application.cfc, examples/starter-app/public/Application.cfc, and the repo-root public/Application.cfc should be regenerated from the template in the same PR or left alone.

Confidence: high

The defect is a missed rename in a single template file, the fix shape is mechanical (assign to the application-scoped name the rest of the file already uses), and no cross-engine, security, middleware, migration, deploy, or DI-container-internals work is involved.

<!-- wheels-bot:triage:2622 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:high -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2623

Spec: vendor/wheels/tests/specs/cli/ApplicationCfcInjectorAssignmentSpec.cfc — failing (4 fails) → passing (4 pass)
Implementation:

• cli/lucli/templates/app/public/Application.cfc (canonical scaffold template — the one wheels new emits)
• public/Application.cfc (framework's own dev/test app)
• examples/tweet/public/Application.cfc
• examples/starter-app/public/Application.cfc

Note: the bug report says "every new application fails to boot until manually patched", but the runtime actually works because Injector.init() (vendor/wheels/Injector.cfc:45) self-registers at application.wheelsdi. The template was nonetheless inconsistent — application.wo was read from the local injector while every other reference (including the very next line in onApplicationStart()) used application.wheelsdi. The fix removes the orphan local in all four copies so the templates read the way the code already behaves at runtime.

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.