Repository navigation
Element wo is undefined in a Java object of type class [Ljava.lang.String #3379
Description
Describe the bug
This has been coming up after moving to Wheels4. Wondering if others see it as well?
Stack trace below:
"Error","ajp-nio-127.0.0.1-8022-exec-5","08/18/26","11:30:07","admin","Element wo is undefined in a Java object of type class [Ljava.lang.String;. The specific sequence of files included or processed is: [...truncated...]\public\Application.cfc, line: 102"
coldfusion.runtime.UndefinedElementException: Element wo is undefined in a Java object of type class [Ljava.lang.String;.
at coldfusion.runtime.CfJspPage.resolveCanonicalName(CfJspPage.java:2855)
at coldfusion.runtime.CfJspPage._resolve(CfJspPage.java:2778)
at coldfusion.runtime.CfJspPage._resolve(CfJspPage.java:2759)
at coldfusion.runtime.CfJspPage._resolve(CfJspPage.java:2722)
at cfApplication2ecfc544280328$funcONAPPLICATIONEND.runFunction([...truncated...]\public\Application.cfc:102)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:668)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:598)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:561)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:456)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:328)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:975)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:921)
at coldfusion.cfc.CFCProxyFilter.invokeAppEvent(CFCProxyFilter.java:102)
at coldfusion.cfc.CFCProxyFilter.invoke(CFCProxyFilter.java:43)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.cfc.CFCProxy.doInvoke(CFCProxy.java:331)
at coldfusion.cfc.CFCProxy.invoke(CFCProxy.java:305)
at coldfusion.runtime.AppEventInvoker.onApplicationEnd(AppEventInvoker.java:263)
at coldfusion.runtime.ApplicationScopeTracker.invokeOnApplicationEnd(ApplicationScopeTracker.java:133)
at coldfusion.runtime.ApplicationScopeTracker.fireBeforeApplicationStop(ApplicationScopeTracker.java:218)
at coldfusion.runtime.ApplicationScopeTracker.cleanUp(ApplicationScopeTracker.java:164)
at coldfusion.runtime.ApplicationScopeTracker.stopApplication(ApplicationScopeTracker.java:200)
at coldfusion.runtime.CFPage.ApplicationStop(CFPage.java:16712)
at cfApplication2ecfc544280328$func$HANDLERESTARTAPPREQUEST.runFunction([...truncated...]\public\Application.cfc:337)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:668)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:598)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:561)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:456)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:726)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:980)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:762)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:4048)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:4012)
at coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:472)
at cfGlobal2ecfc1469752001$func$INVOKE.runFunction([...truncated...]\vendor\wheels\Global.cfc:358)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:668)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:598)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:561)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:456)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:726)
at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:4792)
at coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:4773)
at cfGlobal2ecfc1469752001$func$SIMPLELOCK.runFunction([...truncated...]\vendor\wheels\Global.cfc:41)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:668)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:598)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:561)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:456)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:726)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:980)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:762)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:4048)
at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:4012)
at cfApplication2ecfc544280328$funcONREQUESTSTART.runFunction([...truncated...]\public\Application.cfc:221)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:668)
at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:598)
at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:561)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:95)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:483)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:456)
at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:328)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:975)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:696)
at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:503)
at coldfusion.runtime.AppEventInvoker.invoke(AppEventInvoker.java:115)
at coldfusion.runtime.AppEventInvoker.onRequestStart(AppEventInvoker.java:286)
at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:562)
at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:43)
at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:162)
at coldfusion.filter.IpFilter.invoke(IpFilter.java:45)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:97)
at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:81)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:60)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
at coldfusion.CfmServlet.service(CfmServlet.java:231)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:311)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:201)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:46)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:47)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:170)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:166)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:88)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:534)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:129)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:86)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:71)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:363)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:459)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:71)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:1344)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:2089)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:74)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:976)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:494)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:80)
at java.base/java.lang.Thread.run(Thread.java:833)
To Reproduce
Found in Adobe Coldfusion 2023 error logs. I don't know exactly how it's triggering. That's the main problem. Usually it's fine going into the end of the day. And then overnight at some point it starts happening and the whole site starts erroring. It's production, so a reload=true didn't work. I had to restart the ColdFusion service and then it starts behaving normally again.
I'm guessing it's maybe a timeout issue and application.wo is no longer found? Maybe it's not capturing that fact and re-initializing itself? This doesn't happen every day though, so a little confusing. If I can pinpoint it better I'll attach more information.
Expected behavior
application.wo should be defined. It shouldn't error out. Or make sure it gets re-initialized.
Additional context
- Adobe Coldfusion 2023
- IIS running in front of it on a Windows 2022 server
- Wheels 4.0.5
Activity
wheels-bot commentedon Aug 18, 2026
Wheels Bot — Triage
Classified as bug.
The stack trace pins this down: onRequestStart triggers a restart via
$handleRestartAppRequest()(Application.cfc:337), which callsapplicationStop(). Adobe CF firesonApplicationEndsynchronously during that teardown, and the event handler unconditionally dereferences bareapplication.wo.$include(...). During shutdown on Adobe CF 2023, bareapplication.wono longer resolves to the Global component — CF resolves the name against a stale/torn-down scope and finds a JavaString[]([Ljava.lang.String;), henceElement wo is undefined in a Java object of type class [Ljava.lang.String;. That explains the intermittent, restart-associated symptom (a?reloador environment-switch restart that fires while the scope is being reclaimed), and why only a full CF service restart clears it.Suspected layer
config— application-lifecycle event handlers in the generatedApplication.cfc. The offending code isonApplicationEnd()incli/lucli/templates/app/public/Application.cfc(around line 159 in the current template; line 102 in the reporter's copy). See.ai/wheels/troubleshooting/common-errors.mdfor related lifecycle patterns.Fix sketch
Inside
onApplicationEnd(), stop dereferencing the liveapplicationscope — the only reliable reference during teardown is the passed-inarguments.applicationScope. Route the$includecall througharguments.applicationScope.wo(mirroring how the existing$wheelsBrowserLaunchercleanup already reads fromarguments.applicationScope), and guard the whole block withStructKeyExists(arguments.applicationScope, "wo")so a partially reclaimed scope degrades to a no-op instead of a hard error. Because the fix lives in the CLI-generated template, only newly scaffolded apps pick it up automatically; existing apps need the same edit applied to theirpublic/Application.cfc.Confidence:
mediumThe stack trace makes the failing line and fix shape unambiguous, but the trigger is Adobe-CF-specific teardown behavior (a cross-engine concern that differs from Lucee/BoxLang) and the report is intermittent/not reliably reproducible — the auto-downgrade rule for cross-engine concerns caps this at
medium.wheels-bot commentedon Aug 18, 2026
Wheels Bot — Fix proposed
Draft PR: #3380
Spec:
vendor/wheels/tests/specs/cli/OnApplicationEndScopeGuardSpec.cfc— failing → passingImplementation:
cli/lucli/templates/app/public/Application.cfc(thewheels newtemplate)public/Application.cfc(demo app)examples/starter-app/public/Application.cfc,examples/tweet/public/Application.cfconApplicationEnd()now invokes the Wheels global through the passed-inarguments.applicationScope.wo(guarded withStructKeyExists) instead of the liveapplication.wo, so Adobe CF 2023's unreliableapplicationscope duringapplicationStop()teardown can no longer surfaceElement wo is undefined in a Java object of type class [Ljava.lang.String;. Existing apps should apply the same one-region edit to their ownpublic/Application.cfc.Note: this hardens the exact handler from your stack trace so the crash no longer cascades, but the underlying trigger for the overnight restart isn't reliably reproducible — the PR uses
Refs #3379(notCloses) so the issue stays open for that follow-up. If you can pin down what fires the restart overnight, please add it here.A human review is required before merge. The Reviewer will weigh in shortly. Doc updates (MDX guides,
.ai/wheels/,CLAUDE.md) are handled separately bybot-update-docs.yml.docs: document onApplicationEnd application scope teardown hazard on …
bpamiri commentedon Aug 20, 2026
Thanks Mike — the stack is enough to see what's going on.
Adobe 2023 fires
onApplicationEndsynchronously duringapplicationStop(). That's the reload / overnight restart path. By then the liveapplicationscope is already being reclaimed, so bareapplication.wono longer points at the Global component — CF resolveswoagainst a leftoverString[]and you get exactly this error. Areload=truecan make it worse; a full CF service restart is the only recovery because it rebuilds the scope from scratch.We're changing the generated
onApplicationEndto call througharguments.applicationScope.wo(guarded withStructKeyExists) instead of liveapplication.wo. That's in #3380. New apps get it automatically; existing ones need the same one-region edit inpublic/Application.cfc.That stops the crash cascading. The overnight trigger itself still isn't pinned — if you catch what fires the restart (timeout, recycle, env switch), drop it here and we'll go after that too.
test(cli): cover every shipped onApplicationEnd handler for #3379
mikegrogan commentedon Aug 20, 2026
Thanks @bpamiri. I have a trigger in Splunk to notify me when this error happens. It seems to happen all through out the day. I just didn't notice it for a bit. But usually the wheels 4 app is still running w/o any apparent issue. Not sure why it completely crashed the application earlier in the week. Maybe something else happened at a similar time. Either way, glad to get a fix coming soon. Thanks for all the hard work!
bpamiri commentedon Aug 20, 2026
Thanks Mike — and good to know Splunk is seeing it through the day even when the app stays up. That fits the teardown path: the handler can throw without always taking the whole site down.
The guard is on develop now (#3381; bot draft was #3380). New apps from current
wheels newget it. Not in 4.0.5, and we cannot patch an already-generatedpublic/Application.cfcfrom vendor.For an existing 4.0.5 app, replace the
onApplicationEndbody that callsapplication.wo.$include(...)with:public void function onApplicationEnd(struct ApplicationScope) { if (StructKeyExists(arguments.applicationScope, "$wheelsBrowserLauncher")) { try { arguments.applicationScope.$wheelsBrowserLauncher.release(); } catch (any e) {} } if ( StructKeyExists(arguments.applicationScope, "wo") && StructKeyExists(arguments.applicationScope, "wheels") && StructKeyExists(arguments.applicationScope.wheels, "eventPath") ) { arguments.applicationScope.wo.$include( template = "../../#arguments.applicationScope.wheels.eventPath#/onapplicationend.cfm", argumentCollection = arguments ); } }Key bits:
arguments.applicationScope.wo, never liveapplication.wo, andStructKeyExistsbefore the dereference. Closing against #3381. Reopen if Splunk still lights up after the edit.mikegrogan commentedon Aug 20, 2026
Testing and moving to production. Will follow up in a few days
mikegrogan commentedon Aug 21, 2026
Hi @bpamiri, I tested updating onapplicationend() in public/application.cfc with what's shown above. Unfortunately it didn't help. What's odd is I have multiple wheels sites, and only one seems to be erroring. I'm comparing differences and not coming up with much. When I said splunk earlier, I really just meant the Coldfusion exception logs that get loaded in there.
So previously the error seems to be triggered from onsessionend in the public/application.cfc. Specifically the application.wo.$simpleLock() call.
It's still erroring on the same function. The onapplicationend update might not have been the right function to update?
It's currently erroring every 1-3 minutes over and over for onSessionEnd
Just for completeness, I checked the onsessionstart.cfm and onsessionend.cfm and nothing is in there. I do have something in onapplicationstart.cfm, but it seems to be working fine. It's the same as another wheels application too and it's not causing issues there.
bpamiri commentedon Aug 21, 2026
Thanks Mike — that stack is the missing piece.
The onApplicationEnd guard was the right fix for the original dump (applicationStop() → onApplicationEnd). What's firing every 1–3 minutes is a sibling: Adobe's session reaper (
SessionTracker.SessionCleanUpAgentonscheduler-0) callingonSessionEnd, which still does liveapplication.wo.$simpleLock(...). Same torn-down scope, sameString[], different handler. Emptyonsessionend.cfmdoesn't matter — the crash is in the generated handler before that include ever runs.onSessionEndalready receives the application scope as its second argument. Same pattern as the last paste:public void function onSessionEnd(struct SessionScope, struct ApplicationScope) { local.lockName = "reloadLock" & this.name; if (StructKeyExists(arguments.applicationScope, "wo")) { arguments.componentReference = "wheels.events.EventMethods"; arguments.applicationScope.wo.$simpleLock( name = local.lockName, execute = "$runOnSessionEnd", executeArgs = arguments, type = "readOnly", timeout = 180 ); } }If
wois already gone, this becomes a no-op instead of an exception every couple of minutes. I'll put the same guard in thewheels newtemplate — develop still has the liveapplication.wocall inonSessionEnd— so new apps don't inherit it.One of several sites throwing is consistent with this: the reaper only hits apps whose sessions are actually expiring. Reopening this against that handler.
fix(cli): guard onSessionEnd via applicationScope.wo (#3379) (#3394)
mikegrogan commentedon Aug 25, 2026
Thanks again @bpamiri. That seems to have fixed it. I have no sign of this issue in the Coldfusion exception log for days now. I guess I'm naively wondering why applicationScope.wo wouldn't be set on a running wheels site, but I haven't closely looked at the code in a few weeks. Just happy it seems to be working well.
mikegrogan commentedon Aug 25, 2026
The logs are still bringing up more element wo is undefined issues. Still wondering how this happens where it's undefined.
Line 310 for me is
local.requestTimeout = application.wo.$getRequestTimeout() + 30;Error log
mikegrogan commentedon Aug 25, 2026
At around the same time I also saw this error. Doing a reload=true didn't work. I had to restart the CF service.
What's odd is public/index.cfm is like 5 lines long. Not sure why it's saying 358.
I'm still on wheels 4.0.5. I'll move up to 4.0.6 soon to see if it helps.
##Coldfusion exception log
mikegrogan commentedon Aug 25, 2026
I don't want to hijack this thread, but it all seems related. I did a box install and upgraded on of my wheels sites to 4.0.6. I then took the public/application.cfc and manually updated it too from https://github.com/wheels-dev/wheels/blob/v4.0.6/public/Application.cfc.
When I first load the application (after starting commandbox) I always get this error below. If I simply reload the page it'll load up properly. I don't even need to do a reload=true. I can browse the site like normal.
to test again, i stop the commandbox server and then start up again. Same error again. Reloading a second time fixes it.
It seems like something isn't loading in the right order?
Running: Adobe Coldfusion 2023, Wheels 4.0.6full stack trace
mikegrogan commentedon Aug 25, 2026
Yeah. Discarded all the changed files from the upgrade to 4.0.6 and went back to 4.0.5. Issue went away.
bpamiri commentedon Aug 26, 2026
Thanks Mike — that's a different report from the torn-down application.wo stacks.
The first-boot EmptyStackException at onapplicationstart.cfc:409 ($createObjectFromRoot → Public.$init) on Adobe CF 2023 + CommandBox, gone after you discarded the 4.0.6 files, looks like a real 4.0.6 regression. That line is the Public GUI init. In 4.0.5 Public.$init is include helpers + return. In 4.0.6 and current develop it also calls $scanAndPromoteIncludedGlobals(). The call site itself existed in 4.0.5 (line 419 there). Adobe's popSuperScope EmptyStack on the first request after a cold start fits an include/super-scope nest during that new $init work; a plain reload compiling a second time would then succeed, which matches what you saw.
Stay off 4.0.6 on that CommandBox Adobe 2023 app until we isolate it. Don't copy the v4.0.6 tag Application.cfc over the onSessionEnd guard you already have from develop — that file is unrelated to this first-boot stack.
The 4.0.5 onError wo / EventHandlerInterface pair is still the torn-down scope issue; we'll keep that on its own. Keeping this open.
fix(public): isolate helpers include from $init promote scan
fix(config): harden onError against Adobe applicationScope teardown (#…
bpamiri commentedon Sep 3, 2026
Closing this out — all four manifestations are now fixed on develop (shipping in the next release, 4.1.0; none of these were in 4.0.6):
Application.cfcroutes$includethrougharguments.applicationScope.wo, guarded withStructKeyExists.$simpleLockroutes througharguments.applicationScope.wo, guarded withStructKeyExists.helpers.cfminclude was isolated out ofPublic.$initso Adobe's include page-context pops before$scanAndPromoteIncludedGlobals()runs (the helper-promote itself is unchanged).application.wo.*handling is now wrapped in its own try/catch and degrades to a shared$renderMinimalError()fallback;examples/starter-appandexamples/tweetwere also brought up to the guarded shape (they still carried the pre-First 15 Minutes tutorial fails. The key [WO] does not exist. #2773 unguarded handler).Each fix ships with a structural regression spec. If you still see the error on 4.0.6, that's expected — upgrade to 4.1.0 when it lands.
feat(cli): flag app-template drift in wheels upgrade check (#3491)
bpamiri commentedon Sep 3, 2026
One more thing for the upgrade, @mikegrogan — the
onErrorandonSessionEndfixes live inpublic/Application.cfc, which avendor/wheels/-only swap does not touch (theonApplicationEndguard already shipped in 4.0.6; theonSessionEndandonErrorones are new in 4.1.0). So when you upgrade, also diff yourpublic/Application.cfcagainst the 4.1.0 template and adopt the guarded handlers — or just runwheels upgrade check, which now flags that drift automatically. Details: https://guides.wheels.dev/v4-0-0/upgrading/manual-upgrades/docs(blog): note the Adobe teardown fix and Application.cfc upgrade s…
docs(guides): correct stale 4.1 statements on error email, reload, up…
docs: correct version boundaries on the 4.0-to-4.1 page (rev1-r1)
docs: fix 4.1 upgrade notes — session-cookie range, jBCrypt block, 4.…
fix(cli): warn when wheels upgrade check runs on a CLI older than --to (