Lucee Stable Release 5.3.9.141

news release
#1

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

image
image1024×694 44.4 KB

The 5.3.9.141 builds are up and available for testing via

Changelog

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 2.2.4.5 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 5.3.9.141-RC
LDEV-3680 race condition in getRPCClassLoader

Code Changes

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

9 Likes
#2
#3

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 … https://dev.lucee.org/t/general-question-about-snapshots

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

I did not imagine there would be a difference between 5.3.9.141-RC (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?

#4

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!

3 Likes
#5

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
h
<cflog text="hello"/>
i
<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

#6

[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 ?

How to contribute test cases to Lucee
#7

I added a test for cflog without file attribute
https://luceeserver.atlassian.net/browse/LDEV-3978?focusedCommentId=51175

1 Like
#8

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

#9

installers are up for 5.3.9.141 at https://download.lucee.org/ sorry bout the delay

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

4 Likes