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.
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.
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.
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.
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
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.
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;
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!)
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;
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.
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
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.
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.
