Last week, I attempted to update my dev machine from 6.2.4.24 to 6.2.5.48, and I ran into a few issues.

The first was that the content of the file “[lucee]\tomcat\lucee-server\context\context\graph.cfm” had been replaced with the content from either “.\formtag-form.cfm” or “.\form.cfm” (they only differ by comments and slight differences in “prv.validateEmail”). I replaced graph.cfm from a backup, and it seemed to work fine.

The second was that, on booting up the next day, my "[lucee]\tomcat\lucee-server\context" folder and, therefore, my entire lucee config had been completely wiped. I wrestled with it for a while to reinstate the configuration and re-update to 6.2.5.48 (it kept dropping back to the bundled version). I eventually found the core issue, which appeared to be the updating of cfspreadsheet from 3.0.3 to 3.0.4. After downgrading that back to 3.0.3, everything else was stable. Initial testing of cfspreadsheet right after the 3.0.4 upgrade seemed to run fine.

There were some other extensions that didn’t work (image extension 3.0.1.0 and Lucee Form Tags 2.0.0.6), but they didn’t cause the same config wipe when restarting Lucee. They just gave a ‘jakarta.servlet.http.HttpServletRequest lucee.runtime.PageContext.getHttpServletRequest()’ error. Other full-version number updates seem to work fine (PDF Extension for Jakarta EE Lucee 7+ 1.2.0.12->2.0.1.0 and OWASP 2.6.0.1->3.0.0.14). I’ve only briefly touched upon the jakarta vs javax switchover that’s taking place, so I don’t know if these issues are due to misconfigured extensions or if I would need to update something in my own setup to get them to work.

Any clarification on extension compatibility with Lucee 6 would be appreciated.

Thanks!

• Lucee Version: 7.1.0.43-BETA
• Java Version: JDK 21
• OS: Windows
• Tested with: -Dlucee.qoq.hsqldb.disable=false, -Dlucee.query.allowemptyasnull=true (no effect)

Description

In a Query of Query (QoQ), when using the || concatenation operator in a WHERE clause, rows where the column value is NULL or empty string (“”) are incorrectly excluded from the result set.

This is a regression from Adobe ColdFusion behavior, where those rows are correctly included.

Reproducer

<cfset testQuery = queryNew("campo", "varchar", [
    {campo: ""},
    {campo: "123"},
    {campo: javaCast("null", "")},
    {campo: "456"}
])>

<cfquery name="q1" dbtype="query">
    SELECT * FROM testQuery
    WHERE ','|| campo ||',' NOT LIKE '%,123,%'
</cfquery>

<cfoutput>
    Total rows in source query: #testQuery.recordCount#<br>
    Rows after QoQ filter: #q1.recordCount#<br>
    <cfloop query="q1">
        campo: [#campo#]<br>
    </cfloop>
</cfoutput>

Expected result (Adobe ColdFusion behavior):

• Total: 4
• After filter: 3
• Rows returned: , [null], [456]

Actual result (Lucee 7.1):

• Total: 4
• After filter: 2
• Rows returned: [456] only

Rows with NULL and empty string are incorrectly excluded because ','|| NULL ||',' evaluates to NULL instead of ',,', causing NULL NOT LIKE '%,123,%' to return NULL (not TRUE), which silently drops those rows.

Root Cause

The QoQ engine does not handle NULL/empty string in string concatenation consistently with Adobe ColdFusion. In ACF, concatenating NULL with a string treats NULL as empty string, preserving the row in the result set.

Workaround

Normalize NULL values to empty string before the QoQ is executed:

<cfloop list="#qryFrom.columnList#" index="col">
    <cfloop from="1" to="#qryFrom.recordCount#" index="row">
        <cfif isNull(qryFrom[col][row])>
            <cfset querySetCell(qryFrom, col, "", row)>
        </cfif>
    </cfloop>
</cfloop>

This workaround is not viable when there are hundreds of QoQ statements across a large codebase migrating from Adobe ColdFusion.

Request

Please fix the QoQ engine so that NULL values in string concatenation are treated as empty string, consistent with Adobe ColdFusion behavior. Alternatively, provide a global configuration option (JVM property or admin setting) to enable this behavior.

BTW it seems ACF switched to being case sensitive in 7

You can now opt into being case sensitive as the default via env var, via application.cfc or per query.

Existing behaviour is unchanged

Docs Query of Queries (QoQ) :: Lucee Documentation

So, I now understand how to interact with a module, using LuCLI, but it would be great if I could see a real world example of an actual module.

There wasn’t much documentation about the CFC itself, so I am assuming they are just standard CFCs.

I am still thinking back to when Mark wrote:

{
  "mcpServers": {
    "bitbucket": {
      "args": ["mcp", "bitbucket"],
      "command": "lucli",
      "env": {
        "BITBUCKET_AUTH_TOKEN": "ATATT3xxxx",
        "BITBUCKET_AUTH_USER": "[email protected]"
      },
      "working_directory": null
    }
  }
}

This would suggest that BitBucket is an MCP server and LuCLI can interact with it via Stdio. The second ARG here is the MCP server target, as far as I can remember?

@markdrew Would I be able to see your BitBucket module.
I am intrigued to see how it is used, as an MCP server?

I had a look at:

But I didn’t see any CFCs in there. It would be great if you could add an MCP example, in the examples folder.
This would act as both a module & an MCP example, all in one go.

https://lucli.dev/docs/

Charlesr:

And when you say module, how would you define this? Is it Coldfusion based?

100% lucli modules are of course written in cfml

I am wondering whether you are only using stdio MCP?

Currently, the different kind of protocols for MCP, are the following:

1. Standard Input/Output (STDIO)
2. Streamable HTTP (the modern standard)
3. Server-Sent Events (SSE) (for legacy use)

We are using:

Server-Sent Events (SSE)

Via a NodeJs application, which consists of:

MCP Host
MCP Client
MCP Server

Here is the flow:

1. Lucee Application Server: CFML template →
2. →
3. MCP Host →
4. MCP Client →
5. MCP Server [sends schema to Bedrock] →
6. MCP Client →
7. MCP Host →
8. Amazon Bedrock - [Bedrock analyses the schema and chooses a prompt/tool etc and the. sends back the LLM response] →
9. MCP Host →
10. Lucee Application Server: CFML template

I am wondering at which point I can use your system?

I have a feeling it might be at 3, where I ingest an MCP server-config.json config

{
    "kahootz": {
        "command": "node",
        "args": [
            "C:\\PATH_TO_SERVER\\server\\build\\app\\index.js",
            "http://localhost:3001/mcpserver/sse"
        ]
    }
}

Maybe this image makes it clearer? Forget the left side of the image. Our flow starts with a Coldfusion template [top right hand side]

I am not quite sure why you are sending your BitBucket module to your MCP server?
What is the purpose of your BitBucket module? And when you say module, how would you define this? Is it Coldfusion based?

I have something in mind to allow toggling this in 7.1 at the server, application and per query level

https://luceeserver.atlassian.net/browse/LDEV-6151

Affects version: Lucee 7.0.1.100

Description:

In Adobe ColdFusion 11, the LIKE operator in Query of Queries (QoQ) is case-sensitive. In Lucee 7, it is case-insensitive. This is a breaking change for any codebase migrating from CF11 to Lucee, and there is no global configuration option to restore the original behavior.

Steps to reproduce:

<cfset q = queryNew("col", "varchar", [
    ["Modica"],
    ["MOD-test"]
])>

<cfquery name="result" dbtype="query">
    SELECT * FROM q
    WHERE col NOT LIKE '%MOD%'
</cfquery>

<cfdump var="#result#">

Expected behavior (CF11): The query returns Modica because the LIKE is case-sensitive — Modica does not contain the uppercase string MOD.

Actual behavior (Lucee 7): The query returns no results because Lucee treats LIKE as case-insensitive — Modica is matched against MOD and excluded.

Impact: This affects any application that intentionally uses uppercase patterns in LIKE / NOT LIKE conditions to distinguish between technical node codes (e.g. MOD, TAB, ACC) and real data values (e.g. Modica, Tabarca). There is no workaround that does not require modifying potentially thousands of files across hundreds of sites.

Request: Please either fix the QoQ engine to be case-sensitive by default (matching CF11 behavior), or provide a global configuration option (environment variable, JVM property, or Application.cfc setting) to control this behavior.

Thanks in advance
Stefano

1. LuCLI is meant to be the Swiss Army knife of tools for Lucee. So it is comparative to the great work Ortus has done with Commandbox, just very Lucee-only focussed.
2. Modules in LuCLI are command line tools, so I built a Bitbcuket CLI tool for our CI/CD pipelines as a LuCLI module: GitHub - cybersonic/lucli-bitbucket: A bitbucket module for lucli · GitHub (I have also built A Linter and [Markspresso](https://markspresso.org/ - a static site generator I use for the docs and my blog)
3. I needed an MCP connection to Bitbucket, I didnt want to drop out to other tools and still wanted to re-use some of the specific commands I have in Bitbucket Module
4. I realised that exposing modules as MCP (JSON-RCP) makes sense to me, since we also have a daemon and LSP protocols enabled for other tooling (lucli daemon --port 10000 and lucli daemon --port 5000 --lsp)
5. This makes making MCP clients a breeze and even better, using them and testing them is a breeze since they are literally command line tools anyway

Does that make some sense with regards to the why?

Whatever you do in the modile to connect to some CFML based server is up to the module , whether you are using rest or direct webservices (which If I recall Lucee ↔ Lucee webservices are pretty fast)

This looks really interesting.

We use CFHTTP to connect to our NodeJS + Bedrock MCP Host/Client/Server.
What advantages does LuCLI add over our set-up?
Is the LuCLI a CommandBox like alternative?
I am kind of interested in the MCP server side of things?
Have you managed to create a an MCP server using Coldfusion?

I have found that I needed to use NodeJs to do this part, because of the amazing library:

@modelcontextprotocol

Since Lucee 7.0.3.10-SNAPSHOT, unpinned extensions defined via ( Env var / sysprop / CFConfig.json without a version) now chooses to only install released extensions (unless there are no releases yet, only snapshots) , previously it would pick up the latest whatever, including SNAPSHOTs

unpinned being without an explicit version

https://luceeserver.atlassian.net/browse/LDEV-6147

I am also adding an update all extensions button / cfadmin action to the admin

https://luceeserver.atlassian.net/browse/LDEV-6148

Lucee 6.2.5.48 - Stable LTS Release release

Download: https://download.lucee.org/ Full Changelog: Lucee Server Changelogs - 6.2 Lucee 6.2.5.48 is the stable LTS release following two release candidates. This release focuses heavily on datasource connection pool reliability, classloader / memory, MSSQL compatibility, session management, and admin/extension improvements. We are still addressing a few last issues with Lucee 7.0.2, it’s almost stable!. [image] Docker and Installers Bundle Java 21.0.10+7-LTS ( 6.2 supports up to Java 2…

Added some more installers, fixed some bugs and more importantly sprinkled some AI magic all over the place.

You can now use modules as MCP servers, so for example, you can do:

#install the bitbucket module
lucli install bitbucket

Then in your fave client add the MCP server like:

{
  "mcpServers": {
    "bitbucket": {
      "args": ["mcp", "bitbucket"],
      "command": "lucli",
      "env": {
        "BITBUCKET_AUTH_TOKEN": "ATATT3xxxx",
        "BITBUCKET_AUTH_USER": "[email protected]"
      },
      "working_directory": null
    }
  }
}

You can now also prompt with ease, (remember ALPHA version so feel free to let me know of issues?!?)

lucli ai prompt --text "How much wood would a wood chuck cut if a wood chuck would chuck wood?

Also added backing up of the system! Just in case!

Also in preivous version added runtimes and even added a Jetty runtime.

Have fun!

Rolling out to our non-live sites today

Full Changelog: Lucee Server Changelogs - 6.2

Lucee 6.2.5.48 is the stable LTS release following two release candidates. This release focuses heavily on datasource connection pool reliability, classloader / memory, MSSQL compatibility, session management, and admin/extension improvements.

We are still addressing a few last issues with Lucee 7.0.2, it’s almost stable!.

Docker and Installers Bundle

• Java 21.0.10+7-LTS ( 6.2 supports up to Java 24 , Java 25 requires Lucee 7 )
• Tomcat 11.0.18

Support Lucee

Firstly, huge shout out to everyone in the community who has been collaborating with the Lucee Team with great bug reports, testing and feedback!

Changelog

Datasource & Connection Pool

A major focus of this release was overhauling the datasource connection pool behaviour, fixing several critical bugs that could cause connection leaks, deadlocks, and thread starvation.

• LDEV-5962 - Connection pool config defaults cause connectionLimit to be ignored, causing threads to block indefinitely
• LDEV-5963 - idleTimeout and connectionTimeout were ignored due to the pool evictor being disabled
• LDEV-5964 - Session datasource connections could deadlock
• LDEV-5965 - Datasource connection validation exceptions should reject the connection rather than silently reuse it
• LDEV-5966 - Request timeout could leave phantom connections in the pool
• LDEV-5991 - Datasource idleTimeout default of 1 minute was too aggressive, causing unnecessary connection churn
• LDEV-6051 - Default maxIdle to connectionLimit for better connection reuse
• LDEV-6057 - NullPointerException when a datasource defined in CFConfig.json is missing host or port
• LDEV-6066 - Streamlined verifyDatasource internals

MSSQL

• LDEV-5970 - MSSQL JDBC 13.2.1 throws “result set is closed” when using lucee.datasource.mssql.modern=true
• LDEV-5972 - Fix MSSQL Modern Mode properly

Session Management

• LDEV-6046 - sessionInvalidate() failed to deactivate the old session when using database session storage
• LDEV-6026 - Added system property lucee.session.scope.complex.warn to control the session scope complex values warning logging (also in 6.2.4.24)

Cache

• LDEV-6020 - cachedWithinFlush() returned false with struct arguments on multi-argument functions
• LDEV-6021 - cacheGetDefaultCacheName() did not recognise application-level default caches

Admin & Extensions

• LDEV-6065 - Admin should not allow null support to be overridden via Application.cfc
• LDEV-6067 - Added admin update notification test
• LDEV-6068 - Refactored admin update version handling
• LDEV-6069 - Extension update check incorrectly reported a downgrade as an upgrade due to inconsistent version padding
• LDEV-6073 - Page /lucee/formtag-form.cfm missing with form extension since Lucee 6.2.4 (form tag regression)
• LDEV-6120 - Added support for jakarta-tag-class and javax-tag-class in TLD files, allowing a single extension to target both Lucee 6 (javax) and Lucee 7 (jakarta) servlet APIs

Bug Fixes

• LDEV-5903 - Repeated class loading issues causing memory leaks in Lucee 6
• LDEV-6043 - DecimalFormat returned wrong values for numbers >= 10,000,000 due to silent scientific notation conversion
• LDEV-6048 - Lucee loader version checks had inverted logic and confusing error messages
• LDEV-6063 - cfflush forced Connection: close, breaking HTTP keep-alive
• LDEV-6097 - StackOverflowError when duplicating a CatchBlock with a cause chain
• LDEV-5976 - Error merging cfconfig.json
• LDEV-6056 - Fix regression: invalid PageSource equals check and mapping comparison causing incorrect page resolution
• LDEV-6072 - PageSourceImpl missing hashCode() override causing incorrect equality checks

Extensions Bundled

Upgrading

This is a drop-in upgrade for Lucee 6.2.x. Download from https://download.lucee.org/

If you are running a datasource-heavy application, review your connection pool settings after upgrading — several defaults have been corrected and you may want to tune idleTimeout, connectionLimit, and maxIdle explicitly.

Git Changes

6.2.6 Sprint

https://luceeserver.atlassian.net/jira/software/c/projects/LDEV/boards/53?sprints=276&useStoredSettings=true

Roadmap

As long as the snapshot is just post a RC, I can’t see it being very risky over the RC itself

In those settings, you are telling the server that you don’t want any connections to time out until 10 minutes have gone by… That seems extremely excessive, and could potentially lock up threads for a very long time if anything goes sideways on the server.

My recommendation is that if you have a long-running process – use what @Zackster recommends and run it on another server instance or if you really want to keep it on that instance, bypass the proxy directly by connecting to the port 8888 (or whatever the internal Tomcat servlet is running on). Also make sure to set your CF timeout settings according to your needs.

I process the Excel rows one by one (validating tax codes, normalizing the address, searching for data in my database, and finally running a couple of queries to insert data into the database).

The actual duration of the loop is about 2 minutes.
Before the loop, several functions are defined that perform calculations.

The Excel file and the table where the data is stored both have about 40 columns.

Aside from increasing the proxy timeout, I’d say increasing the memory is what is making the main difference.

The 503 is more Tomcat saying, I’m busy / stuck, probably in heavy GC

I’d also suggest running any batch stuff in it’s own Lucee instance, I’ll give you a free enterprise license for as many cores as you like

I’ve been using java flight recorder a lot these days, it’s a really useful way to diagnose performance over time, i.e your batch.

You can create custom profiles (JFC) to choose what aspects of java behaviour to record and then you can get your LLM to query the file using the command line jfr tool (included with the JDK, it’s not in the JRE)

-XX:StartFlightRecording=name=orm-leak,settings=/path/to/orm-leak-diagnostic.jfc,duration=20m,filename=/tmp/orm-leak.jfr

orm-leak-diagnostic.jfc (7.4 KB)

You can also load the JFR into Java Mission Control (JMC) to visualise the memory growth over time, if memory continues to constantly climb during the batch, try refactoring the code to be more GC friendly ( i.e. more stuff into functions )

I prefer JFR over Fusion Reactor, JFR is very light weight (1-2% overhead) and can be run in prod, but it also has some critical robustness improvements in Java 25

https://luceeserver.atlassian.net/browse/LDEV-6131

Finally, I found a configuration that seems to have resolved the issue.

Obviously, many of the suggestions come directly from ChatGPT.

Do you have any other recommendations to improve Lucee’s performance?
This could serve as a mini guide.
Thank You.

On Plesk
Additional Apache directives:

ProxyTimeout 600
Timeout 600

ModPagespeed off

Additional Nginx directives:

proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
send_timeout 600s;
proxy_buffering off;

On the server::

/opt/lucee/tomcat/conf/server.xml

Modify the connector:
OLD

NEW

nano /opt/lucee/tomcat/bin/setenv.sh

#!/bin/bash

Memory

export JAVA_OPTS=“-Xms2048m -Xmx4096m”

Metaspace (classi)

export JAVA_OPTS=“$JAVA_OPTS -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=2048m”

TLS

export JAVA_OPTS=“$JAVA_OPTS -Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2”

Garbage Collector (G1GC)

export JAVA_OPTS=“$JAVA_OPTS -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ParallelRefProcEnabled”

General optimizations

export JAVA_OPTS=“$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:+ExitOnOutOfMemoryError -Djava.awt.headless=true -Dfile.encoding=UTF-8”

Log GC (optional, useful for monitoring) – I did not include it

export JAVA_OPTS=“$JAVA_OPTS -Xlog:gc*:file=/opt/lucee/tomcat/logs/gc.log:time,uptime,level,tags -XX:+PrintGCDateStamps”

Lucee Log Rotation
New file:

nano /etc/logrotate.d/lucee

content:

/opt/lucee/tomcat/logs/catalina.out {
daily
rotate 14
compress
missingok
copytruncate
}

To give more context, I am working on a component that could be dropped into any application and I want this to be self-sufficient. The component has an AI element to it to analyse some data, and I was hoping to either pass in the name of an AI already defined in the admin, .CFConfig.json or application.cfc OR pass in all or part of an AI definition - say ai type, model and apiKey - from which the component can define its own AI configuration.

I have used cfapplication in the past to allow mappings and datasources to be defined dynamically by components or frameworks by doing something like this:

/**
* @hint adds a mapping to our application
*/
public void function addCFMapping(required string name, required string path){
	local.appMD = getApplicationMetadata();
	local.appMD.mappings[arguments.name] = arguments.path;
	application action="proxy.php?url=update" mappings="#local.appMD.mappings#";
}

// ==================
// I tried to do the same for AI
/**
* @hint adds an ai configuration to our application
*/
public void function addAIConfig(required string name, required struct config){
	local.appMD = getApplicationMetadata();
	local.appMD.ai[arguments.name] = arguments.config;
	application action="proxy.php?url=update" ai=local.appMD.ai;
}

I was trying to do the same for ‘ai’ when I realised that it was missing from the cfapplication definition.

@Zackster The ability to pass the ai config into the CreateAISession function would be great! It would mean we do not have to mess with application settings at all.

I have to run, I reckon also it should allow passing in the ai config struct instead of the service name (the AI functions accept string, not any)

Following the pattern how you can pass in a datasource config struct as the datasource attribute for cfquery?

https://luceeserver.atlassian.net/browse/LDEV-5930?focusedCommentId=75842

Have I got that right, Martin?

And if I can expand the topic a bit, this would not be the only app-level setting that one may find that there is provision to control it as a property of Application.cfc BUT NOT as attribute of cfapplication (at least in CF I’m sure, and seemingly for Lucee from what he’s said.)

And I know there’s no resource from Adobe or at cfdocs.org that outlines what those inconsistencies are for ACF. I don’t expect there’s one for Lucee, either.

And yes, one could dig into the Lucee code to find these differences (though not the admin code itself). For CF (and for Lucee) one could at least use the docs to see how they differ in what can be done in cfapplication vs properties of Application.cfc. But my suspicion is that the docs would not be complete on this matter (for either engine).

I realize it’s not a topic that’s frequently requested, but this discussion reminds me that it is an issue sometimes (even if this ai attribute may be added to Lucee’s cfapplication tag/script stmt).

Hope that’s a helpful and accurate elaboration.

• whether the problem is occurring with the latest snapshots, for either the 6.2 or 7.0, hence my question to Julian
• last know good SNAPSHOT (if possible)

can you describe the value which is being changed / lost?

i.e. a cfc property or variable, changed directly to via an automatic setter

On a server in production where we don’t have the 2 minutes client scope issue.
Lucee 6.2.3.35
Apache Tomcat 11.0.14
Java 21.0.9 (Eclipse Adoptium) 64bit
Windows Server 2019 (10.0) 64bit

On a server in production where we DO HAVE the 2 minutes client scope issue.
Lucee 7.0.1.100
Apache Tomcat 11.0.18
Java 21.0.9 (Eclipse Adoptium) 64bit
Windows Server 2019 (10.0) 64bit

On a related note, in a lab environment, I had been able to replicate the issue with Lucee 6.2.3.35 (separate from production) in my lab environment. So I thought it may have been some config setting somewhere.

I’m going to do further investigation tonight since others are reporting this issue. Happy to provide whatever config details you guys want.

We can configure AI within .CFConfig.json, Lucee Admin and have found that we can also define it within the Application.cfc using this.ai.

However, we do not seem to be able to set the ‘ai’ values using cfapplication - for example:

application action="proxy.php?url=update" ai=local.appMD.ai;

I am guessing that the ‘ai’ attribute is simply missing / not included in Lucee/core/src/main/java/lucee/runtime/tag/Application.java at 7.0 · lucee/Lucee · GitHub

Unless there is already another way to do this, it would be a great addition.

I have found this method very useful for defining datasources and mappings on the fly.

OS: Any
Java Version: 21.0.7
Tomcat Version: 11
Lucee Version: 7.0.2.83-RC

https://luceeserver.atlassian.net/browse/LDEV-5930

Use the older version 1.0.0.6 instead.

Apologies if this is the wrong board, wanted to make sure I was posting to the forum before raising any issues.

I have installed the Argon2 extension in the Lucee admin panel and attempted to use the GenerateArgon2Hash() function but I don’t seem to be able to run this extension’s functions by default.

I’m using a totally fresh out the box Lucee install on a Linux box, and a previously configured one on Windows. Do I need to find/include the library myself?

Thanks,
nb2

Stacktrace below

lucee.runtime.exp.NativeException: Could not initialize class de.mkammerer.argon2.jna.Argon2Library
 at de.mkammerer.argon2.BaseArgon2.hashBytes(BaseArgon2.java:367)
 at de.mkammerer.argon2.BaseArgon2.hashBytes(BaseArgon2.java:359)
 at de.mkammerer.argon2.BaseArgon2.hash(BaseArgon2.java:77)
 at de.mkammerer.argon2.BaseArgon2.hash(BaseArgon2.java:60)
 at org.lucee.extension.argon2.GenerateArgon2Hash.invoke(GenerateArgon2Hash.java:90)
 at lucee.runtime.functions.FunctionHandlerPool.invoke(FunctionHandlerPool.java:40)
 at info_cfm$cf.call(/info.cfm:2)
 at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1114)
 at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1008)
 at lucee.runtime.listener.ClassicAppListener._onRequest(ClassicAppListener.java:66)
 at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:44)
 at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2806)
 at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2793)
 at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2764)
 at lucee.runtime.engine.Request.exe(Request.java:45)
 at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1174)
 at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1131)
 at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:99)
 at lucee.loader.servlet.jakarta.CFMLServlet.service(CFMLServlet.java:41)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:128)
 at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:107)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:165)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:77)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:113)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:83)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:72)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:341)
 at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:424)
 at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
 at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:903)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1778)
 at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
 at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:946)
 at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:480)
 at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:57)
 at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class de.mkammerer.argon2.jna.Argon2Library
 ... 39 more
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: Unable to load library 'argon2':
libargon2.so: cannot open shared object file: No such file or directory
libargon2.so: cannot open shared object file: No such file or directory
Native library (linux-x86-64/libargon2.so) not found in resource path (/opt/lucee/tomcat/bin/bootstrap.jar:/opt/lucee/tomcat/bin/tomcat-juli.jar) [in thread "ajp-nio-127.0.0.1-8009-exec-2"]
 at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:323)
 at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:483)
 at com.sun.jna.Library$Handler.<init>(Library.java:197)
 at com.sun.jna.Native.load(Native.java:622)
 at com.sun.jna.Native.load(Native.java:596)
 at de.mkammerer.argon2.jna.Argon2Library.<clinit>(Argon2Library.java:13)
 ... 39 more

Don’t forget to tell us about your stack!

OS: Linux (Debian 13) & Windows (Windows Server 2022 Standard)
Java Version: Apache Tomcat/11.0.15
Tomcat Version: 21.0.9 (Eclipse Adoptium) 64bit
Lucee Version: Lucee 7.0.1.100

Thanks!

@micstriit fixed it as part of the work on LDEV-6107

Thanks to everyone who tested RC1, the feedback has been very positive.

This RC includes a handful of targeted fixes on top of 6.2.5.37.

Download: https://download.lucee.org/

What’s new since 6.2.5.37-RC

Bug Fixes

• LDEV-6073 - Missing formtag-form.cfm page with form extension since 6.2.4

Extensions / Servlet Compatibility

• LDEV-6120 - Support jakarta-tag-class and javax-tag-class in TLD, allowing a single extension to work across both Lucee 6 (javax) and Lucee 7 (jakarta)

These extension changes are part of a broader effort to allow the same extension versions to work across both Lucee 6 and 7, making it easier to upgrade between versions without needing separate extension builds.

Full changelog: https://download.lucee.org/changelog/?version=6.2

For the full list of changes in the 6.2.5 cycle, see the RC1 announcement

Testing

Please give this RC a spin and report any issues back here

https://luceeserver.atlassian.net/browse/LDEV-6099

can you share a code example?

Same as the maven javasettings syntax for components

The admin will show the current list of installed extensions (needs updating to show GAV instead of GUID)

When starting from zero or light, the core manifest lists the official default extension matrix Lucee/core/src/main/java/META-INF/MANIFEST.MF at 7.1 · lucee/Lucee · GitHub

Require-Extension: 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.0.2,
 org.lucee:image-extension:3.0.0.9,
 org.lucee:esapi-extension:3.0.0.13-RC,
 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.3-RC,
 org.lucee:ftp-extension:1.0.0.4-RC

There’s also a GUID to ext mapping for all the lucee.org extensions GAVs

https://mvnrepository.com/artifact/org.lucee/image-extension/3.0.0.9

Only RC and STABLE versions show up on maven.org, not snapshots

I’ll be updating this with more information and updating docs / admin / etc, just back from a holiday and catching up with the backlog

https://luceeserver.atlassian.net/browse/LDEV-6127?focusedCommentId=75623