Lucee Stable Release

Following up on our stable release, the Lucee team is proud to announce our stable release

The builds are up and available for testing via


LDEV-3028 - “The servlet context has already been initialized” error in Application.log of Undertow deployments
LDEV-3975 - ESAPI functions result in “CTOR threw exception” error with extension
LDEV-3978 - regression: Cflog stops writing to files
LDEV-3980 - jdbc commit issues using transactions and hibernate
LDEV-3976 - RamCache out of memory ignored
LDEV-3979 - Regression: Custom cookie parsing now used over servlet’s cookies

Just one small fix since the
LDEV-3680 race condition in getRPCClassLoader

Code Changes

Give them a go and let us know here if you have any problems


TLDR - I’d like to vote (do we get to vote?) for new revision numbers being automated.

I know there’s a thread talking about differences in snapshots …

In it, version numbers are mentioned as being a manual process

I did not imagine there would be a difference between (what we tested) and the release (what I applied to production without testing) and I did not double check. That’s on me although a new rev number would have been a helpful indicator.

As we (the community) learn and improve - it would be my preference/vote to increment the version number when there are changes. Are there technical reasons this isn’t feasible if automated?

one of the reasons why i prefer the manual increments of build versions, there are 519 commits for 5.3.9, but only 141 SNAPSHOTS, it makes hunting down regressions much easier

Alas @micstriit didn’t bump the build number before making the release, next time we’ll do better!


I’m using the 5.3 Docker image 5.3-nginx

Our application’s lucee-web.xml.cfm has <logging><logger appender="resource" appender-arguments="path:{lucee-config}/logs/application.log" layout="classic" name="application" level="info"/></logging> but application.log remains empty :frowning:

Trivial reproduction

  • mkdir /tmp/a
  • create /tmp/a/index.cfm as
<cflog text="hello"/>
<cflog text="hello2"/>
  • docker run --rm --network host -v/tmp/a:/var/www lucee/lucee:5.3-nginx
  • go to http://localhost/

Expect “h i !” and /tmp/a/WEB-INF/lucee/logs/application.log appears with two entries
Actual : “h i !” but no folder, no log files

If I cd /tmp/a ; mkdir -p WEB-INF/lucee/logs/ ; touch WEB-INF/lucee/logs/application.log I get a .htaccess in WEB-INF created, but still no log entries

chmod -R a+rwx WEB-INF has no effect

[LDEV-3978] - Lucee has been reopened.

The meta question is how things like this keep slipping through ? I didn’t have time to test the RCs (sorry !), but the last time logging broke I produced a two-file repo case, for instance, and this time it’s even simpler because it seems there is no output at all for any logs that don’t specify the optional file argument.

Are these not being added to a test suite ? Can we (the community) help maintain a test suite some where ?

I added a test for cflog without file attribute

1 Like

A post was split to a new topic: How to contributing test cases to Lucee

installers are up for at sorry bout the delay

there is going to be a third release addressing regressions coming out soon


I’m not sure; is that intended to fix the logging ?

@thefalken We went back to 5.3.8 and were waiting for the 3rd release.

I have to wonder with 6 coming soon, is 5.3.9 moot?

Depends on what “v6” means. Is it like Chrome/FireFox where v5.4 is arbitrarily bumped to v6 or is it more like semver where it has breaking changes ? If the latter then I think it’s worth fixing 5.x because who know what other bugs v6 has…

1 Like

same here, was holding off and waiting for the logging fix as well

IDK if it’s even being worked on. Would seem a very serious issue to me.

We’ve dived into this logging issue and it seems to be resolved, waiting on confirmation from @thefalken

I’ve been running since Tuesday (Aug 09) and it stopped logging early yesterday (Aug 10) - appx 24hrs after a Lucee restart.

  • I’ll update to .158 and see if the behavior of “logging works for a while, then stops” is still happening.

thanks for the info, very useful

how large was the log file, which log file, what platform?

1 Like

Detail? You want detail? :rofl:
sorry. Ahem, I’m human.

  • After running several days using I can say logging is still working as expected.

RE: .157 -
The log file (that stopped recording) would be Application.log
Environment is windows.
File size was ~4MB at the time. Rotation is set at 10MB.

1 Like