Announcing Lucee 5.3.5.78 (Release Candidate)

Hello again Lucites! It's February, which means love is in the air! You love Lucee, and that's why we love you. And there's nothing we love more than *shipping* Lucee to you, so today we're enamored to announce the next Lucee release candidate--5.3.5.78.

Here’s the list of tickets covered by the 5.3.5.78 release:

Ticket Summary
LDEV-2671 do check lucee-extensions after startup
LDEV-2632 Lucee inconsistently turns nulls in array to spaces when converting to list
LDEV-2625 Admin - Debugging_logs throwing error when switching debug template
LDEV-2610 CFCatch.type is not always a string
LDEV-2608 Regression in struct implementation causing stack overflow
LDEV-2601 javasettings fails with invalid OSGi Bundles
LDEV-2579 bundle download not following multiple redirects
LDEV-2576 NPE in global log every minute
LDEV-2571 Serialize function does not keep structure type
LDEV-2544 regression: image extension 1.0.0.30-SNAPSHOT imageread/imageinfo locks files
LDEV-2536 Regression w/CFML Sessions: Session scope does not support CSRF Tokens
LDEV-2527 Concurrency: reflection metho d lookups using single sychronous map holding locks under concurrent load
LDEV-2517 unsupported third party extensions warning shown for lucee extensions when offline
LDEV-2513 Regression: can no longer add extension provider in admin
LDEV-2498 NULL value throws error in function data type checking with NULL_SUPPORT enabled
LDEV-2488 java.util.ConcurrentModificationException in StructClear()
LDEV-2479 lucee.runtime.exp.NativeException: java.lang.StackOverflowError
LDEV-2475 Error extracting bundled jars forces download
LDEV-2474 CFLocation in 5.3.3.62 Filling Up Error Logs
LDEV-2465 change log level of some scheduler log to debug
LDEV-2464 datasource log4j appender “insert” no columnlist
LDEV-2463 corrupt extension not reconized
LDEV-2460 Initial Password Setup Not Working
LDEV-2450 5.3 Debug Template Changes Fonts and Downloads External CSS Files
LDEV-2435 Debugging Enable: Need to show the info on Executed page
LDEV-2430 MySQL driver - Wrong object type returned by resultSet.getMetaData()
LDEV-2429 Schedule task - Valid task becomes invalid
LDEV-2425 CFINTERFACE - name attribute throws an error
LDEV-2421 using now() within createODBCdate() doesn’t alway return correct “00:00:00” time
LDEV-2413 Lucee Web and Server Admin Showing JSON Stats Instead of UI
LDEV-2400 The Byte Order Marker of a text file isn’t parsed correctly
LDEV-2394 isNull() not working corrently with null SQL values
LDEV-2392 Admin- Misses the form-field validation
LDEV-2377 Admin - > Extensions - > Applications is very slow due to scope lookups
LDEV-2370 will disable a field
LDEV-2364 debugging improvements and bug fixes
LDEV-2360 modern template execution time column sorting doesn’t work properly
LDEV-2359 CLONE - percentage of total sql execution time is always 0%
LDEV-2358 s3 extension isn’t thread safe - ConcurrentModificationException
LDEV-2357 literalTimestampWithTSOffset in datasource definition in Application.cfc ignored
LDEV-2352 Java Enum use in CFML Incompatible with ACF
LDEV-2330 cfimage writetobrowser ignores height and width
LDEV-2328 Regression: Can’t resize image proportionally in ImageResize
LDEV-2322 Null Pointer Exception when calling server.os.toString()
LDEV-2321 Log messages from org.apache.http.client showing in console
LDEV-2320 Zipping empty folder errors (Regression)
LDEV-2319 /org/lucee/cfml/Query.cfc parseSQL(): uses java reflection unnecessarily to invoke method
LDEV-2317 REGRESSION - java.lang.NoClassDefFoundError - Solr 8
LDEV-2306 CFDUMP doesn’t show the query’s source file and line number
LDEV-2254 modern template breaks pages using jquery plugins

As always, please grab a copy from the downloads site and smother it with as much tough-love testing as you can, and send us any love letters you may be inspired to write (i.e., feedback on the RC).

Please note that this sprint left a large number of tickets not completed, and this reflects the trend I’ve been mentioning in recent months. Our sprints are too large for the increasing complexity we’re dealing with, so we’re switching to a sprint plan that will feature a larger number of smaller, more-targeted sprints. We’ll be publishing a 2020 development schedule in the coming weeks, where we’ll detail the new plan, along with sharing some updates about how we’d like to prioritize tickets in the future (upvoting, etc.).

Happy Valentine’s Day to all the Lucee lovers out there. As always, thanks for listening.

Best,
Patrick

6 Likes

Unfortunately the first tests were not very promising, we found already 2 critical issues in our cms regarding Java interop in this release. I will create tickets.

As I see 5.3.5.79 was already released - Could you please tell me where to find the releasenotes for this release? Thanks

5.3.5.79 is a fix for a s3 problem https://luceeserver.atlassian.net/browse/LDEV-2687

You can easily seen recent activity via the jira dashboard https://luceeserver.atlassian.net/secure/Dashboard.jspa

The ongoing lack of release notes for anything (Lucee and extensions) beyond these RC and Release announcements isn’t a great look, all Lucee users are left flying blind.

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

The current situation of every Lucee needing go and dive off into jira, or look at github commits, just to find out what’s fixed / changed / or possibly broken is rather suboptimal

With regards to extensions, it would be great to see these PRs merged
https://luceeserver.atlassian.net/browse/LDEV-1703

1 Like

Thanks Zac, I voted for LDEV-2535

Regarding 5.3.5.78 - we needed to add JavaCast() in some parts of the code, they worked before without casting. So I am afraid that something fundamental was changed.

Which version were you running previously? did you try clearing the cache?

Of course I just went to look at the performance / caching screen in admin and I’m getting a NPE https://luceeserver.atlassian.net/browse/LDEV-2688

I was running 5.3.3.62 before and tested also the latest stable release. Cleared all caches and reproduced the issues on 2 machines.
Workarounds were javacast("byte[]", ...) and javacast("string", ...) in code which didn’t need casting before.

Generally you’d compile release notes for a Relase, RC or Beta, which Patrick already does and published here in the News/Release channel. For each individual Snapshot build (which only a select group of people would follow along with I guess) all the detail should be in JIRA;

https://luceeserver.atlassian.net/projects/LDEV?orderField=RANK&selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased

Users can also search on that page for the build number to see what was in the build, e.g. 5.3.5.79;

https://luceeserver.atlassian.net/projects/LDEV?contains=5.3.5.79&orderField=RANK&selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased

Unfortunately I don’t know of any way for JIRA to aggregate the release notes across a range of builds like “5.3.5.64 to 5.3.5.79”, but at the very least it should be easier to see all versions within 5.3.5.x I agree.

Do you have any suggestions for making this better? We could tag issues as “Fixed” with a JIRA version like “5.3.5” for every issue against 5.3.5.x builds. That might be better than nothing? Is there anything else that’s problematic, or would you prefer users to not have to look at JIRA at all?

(I’m not involved in this development workflow so I’m just making suggestions, not sure how feasible they are!)

1 Like

5.3.5.79 is a bleeding edge “Snapshot” build (so not a full Release/RC/Beta build, intended only for very specific testing). In JIRA you can see the tickets related to each build by searching for the version number on the JIRA Releases page;

https://luceeserver.atlassian.net/projects/LDEV?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page

So if you search for “5.3.5.79”, click on the version named in the results table, then click “Issues in version” you’ll see the exact ticket(s) that are related to that build/version.

2 Likes

Thanks Justin, I bookmarked this link!

1 Like

As mentioned in the task, there’s actually a JIRA.cfc which can automate this, just like it used to be.

I’d also really like to see this information displayed as a single flat page, no frustrating drop downs or pop-ups limiting access to only viewing one changelog at a time

2 Likes

Can you file a bug? if it’s not reported in jira, it didn’t happen :slight_smile:

The problem is, as always, that it is hard to extract a simple test case.
For instance, if I am executing this method once it seems to work fine.
But if this method is used under load this line will not work - and I receive a message that write doesn’t accept a number: oStream.write(239);

	<cffunction name="writeFileBOM" access="public" output="false" hint="Write to a text file, add BOM">
		<cfargument name="filePath" type="string" required="true" hint="Absolute file path">
		<cfargument name="fileContent" type="string" required="true" hint="Content of the file to be created">
		<cfargument name="throwIfMissing" type="boolean" required="false" default="false" hint="Raise an exception if the file doesnt exists. Default to false">

		<cfset var oFile = 0>
		<cfset var oStream = 0>
		<cfset var oWriter = 0>

		<cfif arguments.throwIfMissing>
			<!--- throw an error if the file doesn't exist --->
			<cfset checkFilePath(arguments.filePath)>
		</cfif>
		<cftry>
			<!--- lock file on write. In order to have a unique name for the lock we use the file url --->
			<cflock timeout="10" throwontimeout="yes" type="readonly" name="#arguments.filePath#">
				<cfscript>
				// create the file stream
				oFile = createobject("java", "java.io.File").init(arguments.filePath);
				oStream = createobject("java", "java.io.FileOutputStream").init(oFile);
				// output the UTF-8 BOM byte by byte directly to the stream
				oStream.write(239); // 0xEF
				oStream.write(187); // 0xBB
				oStream.write(191); // 0xBF
				// create the UTF-8 file writer and write the file contents
				oWriter = createobject("java", "java.io.OutputStreamWriter");
				oWriter.init(oStream, "UTF-8");
				oWriter.write(arguments.fileContent);
				// flush the output, clean up and close
				oWriter.flush();
				oWriter.close();
				oStream.close();
				</cfscript>
			</cflock>

			<cfcatch type="any">
				<!--- throw an error if something went wrong (read permissions, locks or the like) --->
				<cflog text="filesystem.writeFileBOM, error writing to file: #arguments.filePath#. File may be locked or read-only: #cfcatch.message# / #cfcatch.detail#" file="contens_errors" type="Error" application="yes">
			</cfcatch>
		</cftry>
	</cffunction>

The same issue happens with another method which prepares Buld Operations for Elasticsearch:
It works isolated but not under load. Unfortunately I can’t create a ticket - because I am sure that the answer will be: Not reproducible.

did you get a stacktrace?

I’ve filed it anyway as it’s a regression https://luceeserver.atlassian.net/browse/LDEV-2699

Sure, I had a stacktrace but unfortunately forgot to save it. But as I said the error was in the first line where we used oStream to write the BOM. And the message was that the signature was not accepted - number was not allowed. FileOutputStream accepts only byte, byte or integer.
So it seems that some kind of internal casting worked before but in the actual version not always.

maybe this change is the cause? https://luceeserver.atlassian.net/browse/LDEV-2400

Not sure, the issue is not releated to reading of files with BOMs - but execution of Java methods and internal casting of the needed args

This was another change we had to make

can you add that image to the bug?

Sure, will do it now