I ran into this issue. Claude Fable 5.1 wrote this up for me:
Upgrading a 7.0.x server to 7.1.0.204 through the normal patch path (Admin → Services → Update, or dropping the .lco into lucee-server/deploy/) leaves the server without the Mail Extension. Every template that contains then fails to compile:
Error: undefined tag [cfmail], at [2353:20] in [components/flyer.cfc]
Nothing is logged about the extension, so the first sign is the application error log filling up. On our production node that was ~2,100 errors in the six minutes before we rolled back.
I believe this is a small gap in how required extensions are handled on a minor update, not a download problem. Details below.
Environment
- Lucee 7.0.4.34 → 7.1.0.204 via .lco
- Apache Tomcat 11.0.15, OpenJDK 21.0.9, Amazon Linux 2023, installed with the 7.0.1.100 Linux installer (/opt/lucee), so lucee-7.0.1.100.jar is the bundled jar and 7.0.4.34 was itself a patch
- No lucee.extensions env var, no lucee.extensions.config.only, lucee.extensions.install unset (defaults to true)
- Outbound HTTPS to repo1.maven.org, maven-central.storage-download.googleapis.com and ext.lucee.org all work from the node
What the logs show
deploy.log for the update, in full:
“INFO”,“ControllerThread:1349”,“09/01/2026”,“23:54:53”,“”,“deploy handler”,“found [/opt/lucee/tomcat/lucee-server/deploy/7.1.0.204.lco] in deploy folder”
“INFO”,“ControllerThread:1349”,“09/01/2026”,“23:54:53”,“”,“Update-Engine”,“Installing Lucee [7.1.0.204] (previous version was [7.0.4.34] )”
“INFO”,“ControllerThread:1349”,“09/01/2026”,“23:54:56”,“”,“request”,“No new extension available to add to local extension directory”
No “Detected Extensions to install”, no “Installing extension”, no error. lucee-server/context/mvn/cache/ was created at 23:54 and stayed empty. lucee-server/context/required-extension was written as 7.1.0.204-1787326368000.
The manifest does declare it
$ unzip -p 7.1.0.204.lco META-INF/MANIFEST.MF # Require-Extension, unwrapped
org.lucee:mysql-jdbc-extension:9.6.0
org.lucee:mssql-jdbc-extension:13.2.1
org.lucee:postgresql-jdbc-extension:42.7.9
org.lucee:administrator-extension:1.0.0.7
org.lucee:documentation-extension:1.0.0.6
org.lucee:s3-extension:2.0.3.1
org.lucee:pdf-extension:2.0.1.0
org.lucee:image-extension:3.0.0.9
org.lucee:esapi-extension:3.0.0.14
org.lucee:scheduler-classic-extension:1.0.0.1
org.lucee:compress-extension:2.1.0.2-SNAPSHOT
org.lucee:mail-extension:1.1.0.6
org.lucee:ftp-extension:1.0.0.5-RC
mail-extension and ftp-extension are the two entries that are new relative to the 7.0.5.41 manifest. The .lco contains no .lex files, so nothing is bundled either.
Why it is skipped
core/src/main/java/lucee/runtime/engine/CFMLEngineImpl.java (7.1 branch), the required-extensions block. For a minor update (line 476, updateInfo.updateType == ConfigFactory.NEW_MINOR), each required extension that is not already installed goes through this at lines 496–497:
Version since = ed.getSince();
if (since == null || updateInfo.oldVersion == null || !OSGiUtil.isNewerThan(since, updateInfo.oldVersion)) continue; // not installed we do not update
ExtensionDefintion.getSince() reads the since parameter of the manifest entry. None of the entries carry one (grep -c since MANIFEST.MF → 0), so for a missing extension since == null and the loop continues silently. The NEW_FRESH branch a few lines up installs the whole list, which is why fresh installs and the full lucee.jar (which bundles the .lex) are fine and only the patch path is affected.
Same applies to ftp-extension / cfftp, we just don’t use it.
Suggested fix
Either of:
- Add since to the entries that moved out of the core, e.g. org.lucee:mail-extension:1.1.0.6;since=7.1.0.0 and org.lucee:ftp-extension:1.0.0.5-RC;since=7.1.0.0. RHExtension.toExtensionDefinition() applies name=value tokens after the Maven coordinate to the definition, so this parses today.
- Bundle the Mail (and FTP) .lex inside the .lco so deployBundledExtension picks them up on NEW_MINOR.
And, whichever is chosen, a log line at INFO when a required extension is skipped for lack of since would have made this a two-minute diagnosis instead of a rollback.
Workaround for anyone hitting this
Put mail-extension-.lex (Maven Central or https://ext.lucee.org/mail-extension-.lex) into lucee-server/deploy/ together with the .lco, so it installs when the new core boots. Note the extension in the manifest, 1.1.0.6, also has the spooled-mail serialisation bug from Lucee 7.1.0.204 / Mail Extension 1.1.0.6 — spooled cfmail silently dropped (NotSerializableException: sun.nio.cs.UTF_8) (LDEV-6455), so you probably want 1.1.0.8 or later once it is out of RC.
