Hello. I'm executing the query with incorrect decimal value ("6 5") in Lucee 5.3.10.120.

<cfquery name="qryUpdateFTs" datasource="#pvtDSNInnovare#">
    UPDATE Policys2PrFeesTaxes
    SET 
        CommissionGANB = <cfqueryparam cfsqltype="CF_SQL_DECIMAL" value="6 5" scale="2">
    WHERE 
        Policy2PrFeeTaxID=<cfqueryparam cfsqltype="CF_SQL_INTEGER" value="2">   
</cfquery>

In debug I see (and in database):

UPDATE Policys2PrFeesTaxes
	SET 
		CommissionGANB = 45082
	WHERE 
		Policy2PrFeeTaxID=2

ACF gives error "*Invalid data 6 5 for CFSQLTYPE CF_SQL_DECIMAL."* Is it bug in Lucee? What's the conversion algorithm converts "6 5" to "45082". I see incorrect value "36865.00" in database and need to understand what user has entered.

bordering on pornographic https://github.com/lucee/Lucee/actions/runs/5135427735/jobs/9240830323#step:7:11 with hsqldb 2.7.2, Lucee 6.0 core is now finally CVE free baby https://luceeserver.atlassian.net/browse/LDEV-1526

I'd really, really, really fucking appreciate it if everyone can try out 6.0.0.419 with their test suites

somehow this makes a big difference, now 5% with 6.0.0.419 https://luceeserver.atlassian.net/browse/LDEV-2127?focusedCommentId=53841

i am fetching data from query and then in one of tables, data is updated, first time when i go to page, i do not get updated data, i refresh the page again i get the data, there is no caching being used, how can i make sure everytime data fetched is fresh and not cached

There is one bug in Lucee with commandbox, I couldn't find the solution anywhere. I was testing ocr functionality for that purpose I used the tess4j. its have dependencies on JNA and I found that its already exists. see the attached screenshot. Then I tried the following script

<cfset tesseract = createObject("java", "net.sourceforge.tess4j.Tesseract")>
<cfdump var="#tesseract#">

but it's throwing the error in the native dump.cfc file.

Lucee 5.3.10.120 Error (java.lang.NoClassDefFoundError)
Message	com/sun/jna/Pointer
Stacktrace	The Error Occurred in
/Dump.cfc: line 111
called from /var/www/wwwroot/scanmagic.cfm: line 4

What could be the possible fix?

Lazy Q: Is there a way to get Lucee to keep its log entries to one line, rather than just spewing raw stack traces (etc) into the logs over hundreds of log lines?

Tangent to the thread above: I am also seeing log entries being written for handled exceptions sometimes. I have not got to the bottom of it, but is anyone seeing this? EG: an exception that occurs within a try/catch should NOT be logged by Lucee?

Is it possible to initialise the LOCAL scope like this:

function foo(){
            
  var local = {};
  
  local = {
    strReturn = {
      criteria = {} 
    },
    strCompetenceTemplate = “”,
    aCriteria = [],
    iGlobalCnt = 0,
    lSelected = ""
  };
  WriteDump(var=local.strReturn);
}

When I try this, I get an error saying that the local scope is empty.

Before I raise a ticket, is there any reason I shouldn't expect the

sessionCookie

settings to be included in the

getApplicationMetadata()

result? It does on CF. Second: given it's not exposed there, how can I determine the values for this @ runtime? Is it hidden away somewhere else?

Any success anyone having installing lucee and acf on MacBook Pro M1 chip onwards

I have cherry picked the java changes out of 5.4 hibernate PR https://github.com/lucee/extension-hibernate/pull/37

When I hit a query timeout in Lucee (lucee-light@5.3.10+120), I'm seeing the following in the logs:

ERROR: canceling statement due to user request;lucee.runtime.exp.DatabaseException

Lucee Docker Hub guidance (from https://hub.docker.com/r/lucee/lucee) is still referring to 5.3.9.133 as the latest stable release. Isn't it 5.3.10.120?

I just uploaded images based on various Lucee images from Docker Hub to our repo, where we have snyk scans running automatically. Results:

Does/will Lucee support SSL/encrypted connections to SQL server via some driver or other mechanism? I have a financial services client that wants to look at encryption at rest and in transit. https://blog.devart.com/column-level-sql-server-encryption-example-using-sql-complete.html

Ha this looks so cool, createObject(“wasm” https://www.graalvm.org/latest/reference-manual/wasm/

Hey all.. has anyone come across this before? It seems one cannot use the Elvis operator with the return value (struct) of a function.

v = foo()["bar"] ?: "xxx";

v = foo().bar ?: "xxx";

https://trycf.com/gist/b7f329f163d1cb6389394516275fb816/lucee5?theme=monokai

fix the code search testcases links from docs, the new github search broke the old link https://github.com/lucee/lucee-docs/pull/1375

The Lucee documentation indicates that there is supposed to be a queryToStruct() and query.toStruct() query member function, but neither of these seem to exist in Lucee 5.3.10.97. I don't see anything in the change log (https://docs.lucee.org/reference/changelog.html) that indicates that these functions were added or removed. I'm assuming the documentation is just wrong, but should these functions exist?

Can anyone advise how can we prevent the inline logging of SQL requests to the lucee trace.log? Running on Lucee 5.3.10.120 When investigating a recurring issue with blocked threads (and we believe DB Deadlocks) within one of our client’s applications, we keep seeing something similar to the attached image with Fusion Reactor Profile for the blocked requests. Specifically we are seeing close to 100% of the profiled time for the request being taken up within a call to log4j from within the cfquery tag. This was somewhat unexpected, as we have not opted to perform any logging from within the cfquery tag. When checking the lucee log files within our hosting environment, we could see several log entries made to lucee trace.log similar to the following:

"WARN","XNIO-1 task-17","06/07/2023","12:31:57","cftrace","[1686137517872 ms (1st trace)] [/usr/local/lib/serverHome/WEB-INF/lucee-web/components/org/lucee/cfml/Query.cfc @ line: 30]- [arguments.sql=""{EXAMPLE SQL}""] "

This does not appear to be every trace which is logged - however it is significant enough for us to see over 2.47 Million requests logged in the last 4 weeks on one of the busier applications we host! Can anyone advise what we can do stop this being logged? Also -

1686137517872 ms

which this query has been logged as taking, equates to ~53.5 years… which is quite impressive… I hadn’t realised our application had been running that long! (or that Lucee was that old… or AWS… or the internet in general really!!!) Digging into the code for the cfquery tag,I did find the following lines - but they appear to be in a different format, and appear to be referring to and writing to datasource.log https://github.com/lucee/Lucee/blob/5.3.10.120/core/src/main/java/lucee/runtime/tag/Query.java#L778-L782 datasource.log??? Well, that’s not something which we have configured within log shipping for our production environments - as this was not a file which Lucee produced by default at the time we initially configured our log shipping with an earlier version of lucee (probably 1 5.1 variant) So I fired up a new local instance of the application, and then checked the lucee web logs folder… and… 82,000 log file lines just from starting the app and hitting a few pages. This does indeed appear to be logging every single SQL request to to the datasource log file. Looking at the the following logic from Lucee’s Query.java:

Log log = ThreadLocalPageContext.getLog(pageContext, "datasource");
if (log.getLogLevel() >= Log.LEVEL_INFO) {
	<http://log.info|log.info>("query tag", "executed [" + sqlQuery.toString().trim() + "] in " + DecimalFormat.call(pageContext, exe / 1000000D) + " ms");
}

Ok, so If I read this correctly… It appears that • Lucee is retrieving the log object for datasource.log • Lucee is comparing the configured logLevel for datasource.log to Log.LEVEL_INFO and if datasource.log logLevel is higher than Info, then write the query to the datasource.log file Ok - so, next I look at the implementation of the Log interface to see how the log levels would be compared: https://github.com/lucee/Lucee/blob/5.3.10.120/loader/src/main/java/lucee/commons/io/log/Log.java#L24-L46 Ok - so,

LEVEL_INFO = 1;

So if the datasource.log log level is set to anything other than

LEVEL_TRACE

then every SQL statement needs to be logged to datasource.log??????? 🤦 So - please tell me, am I interpreting that correctly? If datasource.log is configured to LEVEL_TRACE then nothing will be logged, but if it’s configured to LEVEL_INFO / LEVEL_DEBUG / LEVEL_WARN / LEVEL_ERROR / LEVEL_FATAL then nothing will be logged??? If that’s correct, then isn’t that the wrong way round - if we set a log level to LEVEL_WARN - doesn’t that mean “only log entries to the file which are of LEVEL_WARN or above?” I.e. the higher the value, the less should be logged? It feels like there is a bug with the logic here… and the condition has been reversed. Can I just get confirmation that my understanding (not being primarily a java developer) is correct here? I suspect that a similar logic error may be responsible for the copious (all though not as extensive) logging to the trace.log - but haven’t identified the specific location where that takes place… if anyone can enlighten me, that would be appreciated.

What do you make of this:

// C.cfc
component {

	static {
		final static.usingLiteral = {
			subKey = "value"
		}
		final static.usingDots.subKey = "value"
	}
}

<!--- test.cfm --->
<cfscript>
writeDump(C::usingLiteral)
writeDump(C::usingDots)
</cfscript>

Looking to migrate a Fusebox and Mach II CF applications to Lucee - are there any compatibility issues that we need to be aware of ?

I’m just building up a new EC2 with Lucee and wondering what the latest LTS supported JVM is? The default Lucee install has 11.0.18 (Eclipse Adoptium) 64bit and I see that there is a 11.0.19 available. Is 17 LTS supported?

do you read the release notes?

Aha! Java 17 is not fully supported yet. 11.0.19 it is then.

Sorry, another question - the S3 Resource Extension seems to have lots of Snapshot releases but appears to be stuck at 0.9.4.156 on the ‘release’ version. Is there a release version later than 0.9.4.x?

(cross post) please read and vote https://dev.lucee.org/t/lucee-5-4-0-65-release-candidate/12657/6

Can any MySQL users give me some advice on Datasource connection settings? I am seeing a lot of error messages:

Caused by: org.hibernate.TransactionException: JDBC commit failed
        ... 53 more
Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: The last packet successfully received from the server was 389,215 milliseconds ago. The last packet sent successfully to the server was 389,215 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

Previously I did a lot of research / googling and found that the people that had "fixed" the issue were stating that they manually reset the connection pool every 6 hours. (I don't exactly remember but it was something about the (DB?) default connection timeout) And ultimately started running a scheduled task every 6 hours (5h 55m) that calls dbPoolClear(). It "seemed" to work - but the messages are back. At the same time as implementing the scheduled task, I also changed the timeouts in the Lucee / Datasource settings to; Connection limit (max): 100 Connection idle timeout (in minutes) : 5 Connection timeout : 15 I thought, all the above fixed my problem - but I am seeing the "The last packet successfully received from the server was XXX milliseconds" again and thought I better ask, again for some help / recommendations. • Is there was anything I had misconfigured (above) • Is there some other Datasource setting I should check / change? • Any non Datasource setting changes I should check / complete.