Merriam-Webster defines “silly season” as “a period (such as late summer) marked by frivolous, outlandish, or illogical activity or behavior.” Well, we here at Lucee must be out of touch with popular trends, because the past few months have been the exact opposite of silly season! It’s been a dead-serious development push (busiest stretch ever, as I described in the Mid-Year Development Update and other posts). The result is two shipments of Lucee today–a final build (5.3.3.62) and a new release candidate (5.3.4.54). Read on for the deets!
First, here is the final list of tickets covered by 5.3.3.62:
Please head over to the downloads site and grab one/both of those, and thanks in advance for any and all testing/feedback.
Next, returning to the topic of the remaining development schedule for 2019, we’ve come up with the following plan:
At least 1 more final release (5.3.4).
At least 1 more release candidate (5.3.5-ish).
Catch-up on any lingering bugs/problems, in particular those related to security, or those that are blockers to anyone wanting to upgrade to the latest production release of Lucee, along with catch-up on pull requests (hears a loud “huzzah!” from the community on this one!).
Progress on Lucee 6 (though not necessarily a beta or even an alpha).
Regarding #1, we’re now in the RC period for 5.3.4, so we’ll make that final depending on how regression testing/community feedback go. Regarding #2, we’ll decide when the next monthly sprint will take place based on how things go with numbers 1, 3 and 4. #3 may push #2 later on the calendar, if we find that we need to make a substantial development push to get caught up/stable/etc. We’ll have more info about #4 as we get closer to CFCamp. We’ll definitely be previewing at least some Lucee 6 goodness at CFCamp, and based on how far we get with that effort, we’ll then decide on the schedule for a formal alpha/beta/release candidate plan for Lucee 6.
Next, a bit more about #3 above. Late last week, and into this week, we put in a really substantial triage effort that covered over 200 tickets, almost all of which were created in recent months. So, if a ticket (or tickets) important to you isn’t baked into either this final release or the RC, then please take a look at Jira to see if there’s an update to your open ticket(s). Again, we’re going to plan the rest of this year’s development efforts around finishing the year strong, and making sure we’re caught up on especially critical items, so comment/upvote, etc., and we’ll be ready to react.
As always, holler with any and all questions/comments/commentary, and thanks for listening!
The stable release and the RC (to promote testing) have been added to ForgeBox and can be used in CommandBox or the Ortus Docker images as of yesterday.
This morning, I also worked with Micha to create a new functionality on the Lucee update provider feature generates CommandBox CF engines on the fly so it can serve up Lucee Light engines (no extensions) as well if you’d like to try running your site on them. I may start putting these on ForgeBox, but for now, you can start a server using the Light versions like so
Notice the ?light=true on the end of the URL. That’s the new bit You can choose exactly what extensions you want to “layer on” to your Light server with JVM args. This example would start up a Light server, but add in the Admin and MySQL JDBC driver.
server set app.cfengine="http://update.lucee.org/rest/update/provider/forgebox/5.3.3.62?light=true"
server set jvm.args="-Dlucee.extensions=CED6227E-0F49-6367-A68D21AACA6B07E8,7E673D15-D87C-41A6-8B5F1956528C605F"
server start
I would like to see these on ForgeBox! We already start servers using -Dlucee.extensions.install=false but I think this would be much better, as we would not have to download the unused extensions in the first place.
This is great but it seems that you can’t specify a version or include a name to help identify each extension.
Apparently you can do both with Env Vars, but if I want different commandbox servers in the same OS environment to use different sets of extensions I’d need to use system properties in my individual server.json files rarther than EVs.
The environment variable and system property are equivalent to each other, so you should be able to use the same value in either place to specify your extension version.
@Julian_Halliwell If you’re going to have spaces in the arg, you need to quote it. And if you’re setting it in the server.json, remember that the standard escaping rules for storing the quotes in JSON apply as well.
Another way to accomplish the same thing is to install the CommandBox Dotenv module and place a file called .env in your web root with the contents:
Any key/values in that properties file will get added to the server for you. There’s no quotes needed there and there’s less escaping to worry about since it’s not inside of JSON. And, of course, each site can have it’s own .env file.
I did try an extension without spaces in the name and also one with just the version (no spaces), but got the same error so I don’t think that’s the issue.
Sounds like the Dotenv module is the best approach though. Thanks Brad.
Yes, the lack of quotes was your issue. There’s other reasons to use quotes too, the error message implies the semi colon was involved. All you have to do is run
server start --debug
and you can see the exact JVM args being used. You’ll find that a character such as a space or semicolon which wasn’t quoted broke the parsing of the args.
There appears to be some naming conflict with 5.3.4-rc+54
This works fine for starting the server but fails to stop the sever from the command line
Looks like the stored state of the server has a different specification. i.e. 5.3.4+54-rc requiring the server be stopped from the tray icon.
@pat.moody You are correct, the version in the box,json had the build num in a different place, but that shouldn’t; affect stopping the server. More likely, you have a duplicate server with the same name and the wires are getting crossed. Run server list to verify and forget the duplicates. Also, I updated the version number but you’d need to clear the download from your artifacts to get the new version.,.
Cheers Brad, something bizarre was going on there. I don’t know if it was after installing FusionReactor. I’ve made a fresh start without FR and it is back to normal. Just noticed I was still on CB 4.7 so I’ve updated that too.
@pat.moody Ah, yes FR throws a monkey wrench in the works. The debugger dll library tends to get locked by Windows and they don’t release for a few seconds after the server has stopped. So the restart command sees that the ports are released, but the DLL files are still locked. I haven’t; found a way around this other than to wait a few seconds and run the “start” command again.
There was a big commit (with no linked jira task ) which was meant to address concurrency issues in Lucee which seems to have broken multiple things since 5.3.3.61, this is still an issue with 5.3.4 RC
Concurrency: reflection method lookups using single sychronous map holding locks under concurrent load [LDEV-2527] - Lucee
These look like major regressions which will waste lots of end user (developer) time struggling with these bugs, I think these should be blockers for the 5.3.4 release.
5.3.4 is still at RC, I think these justify a code review of that commit, fixes and a new RC, otherwise, what’s the point of having RC process if major regressions don’t get addressed?
You can choose exactly what extensions you want to “layer on” to your Light server with JVM args. This example would start up a Light server, but add in the Admin and MySQL JDBC driver.