New Release (5.3.7.43)

[micstriit]

There is a new Release ( 5.3.7.43 ) available to download from our download page https://download.lucee.org or via the Lucee Admin.

Highlights

Lucee now uses https for all updates and downloads

Thresholds for request timeouts (experimental)
You can now set a Memory,CPU and/or Concurrent request threshold for Lucee, if set Lucee will not kill requests reaching the timeout when the defined threshold is not reached. [LDEV-3019] - Lucee

cfLogin (experimental)
You can now define a private key/salt for cflogin that then will be used to encrypt the data send to the user when loginstorage is set to cookie. [LDEV-3013] - Lucee

xmlValidate
Supports passing multiple XSD files into the function. [LDEV-2889] - Lucee

jsonValidate
a new function to validate JSON, optionally using a JSON schema (via the optional extension “JSON”). [LDEV-1188] - Lucee

Optional query cache
In case the cache used for a query with “cachedwithin” fails, the query itself will no longer throw an exception, instead it will log the error to the application.log. So a failing cache does not break your website. [LDEV-3058] - Lucee

sameSite
(lax, strict, none) cookie options for and session cookies.

SameSite cookies - HTTP | MDN

// via Application.cfc
this.sessionCookie.sameSite = "strict";
this.tag.cookie.sameSite = "strict";
<cfcookie name=”id” value=”#createUUID()” samesite=”strict”>

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

Bug fixes and improvements in the code, the focus for the 5.3.7 sprint was stability and regressions, details in the tickets below.

Tickets addressed in this release cycle

LDEV-2889 - allow to use multiple xsd files with XMLValidate

LDEV-2860 - Error - Unable to resolve lucee.image.extension

LDEV-2857 - directoryDelete() can throw NPE

LDEV-2852 - Showing wrong result - using FindOneOf() Member function

LDEV-2834 - Admin-Update, seems has wrong if No upgrade/downgrade version

LDEV-2814 - Lucene and S3 extension get (re) deployed after each update

LDEV-2808 - Regression - Intermittent ClassNotFoundException exception when compiling

LDEV-2798 - Method code too large! after update from 5.3.4.80 to 5.3.5.92

LDED-2791 - Can’t access plugins install at server level in context web admin

LDEV-2779 - NPE uninstalling an extensionLDEV-2655 - autocommit=true always set

LDEV-2654 - Floor() / Int() can round a number down to > 1 less than its value

LDEV-2651 - Scan deploy folder for extensions to install on startup

LDEV-2597 - createObject (“webservice”, …) broken since 5.2.9.31 (SOAP v1.1)

LDEV-2578 - Reduce INFO logging

LDEV-2568 - CFCOOKIE - Incompatibility with ACF

LDEV-2558 - Extension management broken inside CommandBox CLI/JSR-233

LDEV-2533 - Status showing open - when using Fileclose()

LDEV-2524 - DeserializeJSON does not properly handle uppercase letters in basic multilingual plane values

LDEV-2505 - getFileInfo() is really slow

LDEV-2487 - QoQ and QuerySort don’t sort varchar columns correctly

LDEV-2312 - java.lang.Thread.State: BLOCKED at lucee.runtime.op.date.DateCaster.toDateAdvanced

LDEV-2288 - Lucee engine reset() kills current thread (regression)

LDEV-2277 - REGRESSION - createObject webservice WSDL error on generating token

LDEV-2158 - Query sorting ignores leading hyphen

LDEV-2061 - getting exception from release in Jetty Servlet engine

LDEV-1846 - CFDocument fails to produce pdf with lmdp locked error

LDEV-1506 - server and extension updates are insecurely downloaded over http

LDEV-1236 - Add SameSite-attribute to cfcookie

LDEV-3050 - make query cache optional

LDEV-3040 - GetTagData should return the tag attributes in an ordered struct

LDEV-3019 - add possibility to add a cpu/memory/concurrent request threshold for request timeout

LDEV-3013 - add support for a private key with cflogin

LDEV-2993 - SameSite for CFCookie doesn’t send None values

Contributors

Our thanks goes to all Contributors for this release candidate:

• Mircea Botex
• kabutotx
• Michael Offner
• Andrew Penhorwood
• Pothys Ravichandran
• Igal Sapir
• Zac Spitzer
• VovanVod

[Zackster]

here is a link to all the issues

https://luceeserver.atlassian.net/issues/?jql=issueKey%20in%20(LDEV-1188%2CLDEV-1236%2CLDEV-1506%2CLDEV-2158%2CLDEV-2487%2CLDEV-2505%2CLDEV-2524%2CLDEV-2533%2CLDEV-2558%2CLDEV-2568%2CLDEV-2654%2CLDEV-2808%2CLDEV-2814%2CLDEV-2834%2CLDEV-2535%2CLDEV-2681%2CLDEV-2807%2CLDEV-2876)

• the default log level for Application.log is now error, for new installs (I disagree with this change), so WriteLog(“something”); won’t log anything… you need to change the log level in the Admin

The s3 Extension also got some new functions

S3 :: Lucee Documentation

add function S3Read,S3ReadBinary,S3Write

The smtp/mail issues are going to be addressed in the current 5.3.8 sprint

Log in with Atlassian account

[thefalken]

@Zackster

for new installs … WriteLog(“something”); won’t log anything…

I think this is wrong too.

But no one seems to know why or where it has been changed.

If it’s to fix something, that’s a case to be made, but it seems to have been made without wide discussion, and it’s a huge change in default behavior for a function.

[micstriit]

the function itself did not change, only the default log level of the application log from “info” to “error”.
This only affects new installations and not existing ones.
The reason for this is very simple, we increased the use of the application.log a lot inside Lucee, what produced big logs for some customers. It is not good practice to have the log level set to “info” by default, having the same log level for all logs by default makes much more sense.

Sorry we was not aware that this will have an impact on some customers, otherwise we would communicate this better.

In environment like docker always explicitly define the log level, if it matters and it should not be “error”.

[Zackster]

but the solution should be that either the Lucee generated logs either go in a different log file, or get set to DEBUG or TRACE.

something like daemon.log or context.log or server.log

WriteLog / CFLOG is effectively broken out of the box for new users, just sucks.

I’ve been caught out by this change quite often myself (and wasted time trying to figure out why) and I’m well aware of this change

[Julian_Halliwell]

@micstriit

The reason for this is very simple, we increased the use of the application.log a lot inside Lucee, what produced big logs for some customers. It is not good practice to have the log level set to “info” by default, having the same log level for all logs by default makes much more sense.

I can see both sides of this, but for some time I’ve been using my own setup script to configure all context log levels to “ERROR” because so much “INFO” stuff was being written to application.log it was hard to see the errors (which are generally what I need to pay attention to).

Whenever I use WriteLog() to deliberately record “info” level entries I specify a custom log file.

@micstriit is the default level for custom logs also set to “error”? (I’m trying to test it myself on a 5.3.7.43 commandbox instance but for some reason can’t get it to write any logs to any file at any level!)

[Zackster]

@Julian_Halliwell

Whenever I use WriteLog() to deliberately record “info” level entries I specify a custom log file.

yeah, I always just set this.tag.log.file = this.name; in my Application.cfc constructor

[thefalken]

@micstriit

we increased the use of the application.log a lot inside Lucee, what produced big logs for some customers. It

Ahh. So now we find out why all those “OSGi” messages suddenly appeared on every single request ?

I think that the problem with large application.logs was caused by Lucee adding additional internal logging, of things that did not traditionally get logged.
The solution I’d have gone for would be to fix that would be to use a level lower than info for whatever it was, add a filter so it doesn’t get written or similar, not make a change to how writeLog() works; I get what you say about “the function did not change” but decades of ColdFusion users know that “writelog(‘foo’)” will appear in the application.log file, and have got that expectation in their applications.
Why should this expectation get broken, and thus extra work be created, just because they’ve upgraded their server ?
I mean, great it you have a custom log file name in every app (does that even work ?), or a deploy system that is able to set a server default at build time (we actually do, because we needed to deploy with application.logs working when they were missing entirely) etc etc., but sucks if you don’t.

Changing a default like this, even for “only new installs” is the wrong fix to the underlying issue. It feels like you’ve used a very large hammer to solve a self imposed problem that had other solutions that would have had no external impact.

[thefalken]

@Julian_Halliwell

@micstriit is the default level for custom logs also set to “error”? (I’m trying to test it myself on a 5.3.7.43 commandbox instance but for some reason can’t get it to write any logs to any file at any level!)

There’s a regression I found in 5.3.8 ( [LDEV-3081] - Lucee ) that kills all writelog() (at any log level) output stone dead.
I wonder if something is wrong with logging in the latest 5.3.7 too then.

[Zackster]

Now that Lucee docs is running 5.3.7.43 stable, the order of Arguments for Tags follows the XML definition, rather than being random. See [LDEV-3040] - Lucee

Application.cfc / cfapplication :: Lucee Documentation

cfquery :: Lucee Documentation