New Stable Release (5.3.8.189)

Thank you @andreas, it worked.

But it will be very convenient to have on each Lucee release automatically built Windows installer.
When I make new fresh installations it is more easy to install it without additional steps.

Glad it worked!

Yes @karniolus, I totally agree that these files should be automatically built, just like the other files are!!! That’s how it should be. The issue is that the installer was always supplied with courtesy by the viviotech team in the past, but the main person behind the installer files and deploying it unfortunately left viviotech.

I know that the Lucee Core Team recently forked the installer files. See:

They are working hard to supply the files and everything smoother in future. They are also working hard to make it even better (e.g. I know they would love to add ngnix support to it and even Apache2 on Windows).

But they have/had lots and lots of other priorities, such as getting the latest stable release out with all the added functions, bug fixes and doing it without regressions. Besides, they are working also on Lucee 6.

That’s why they need our help from the community with contributions in whatever/wherever we can contribute. Lucee lives a lot from contribuitions.

1 Like

the windows installer is ready, just the download site, isn’t showing it

https://cdn.lucee.org/lucee-5.3.8.189-windows-x64-installer.exe

3 Likes

Thank you for quick response!

A post was split to a new topic: Mappings not working with IIS and Boncode

Great effort from everyone involved

1 Like

I’ve always upgraded Lucee from the admin section. I understand that doesn’t include updated Java or Tomcat versions? If that’s the case what are the procedures for upgrading from the windows installer? Thank you!

Updating Java is easy, you can just stop Tomcat and replace the JRE in the install folder (C:\lucee\jre)

Or you can just point it at a different folder, using the Lucee-Tomcat Service Control

Tomcat is a bit more complicated, depending on which version you are upgrading from

1 Like

Good one! My prefered option as of today is:

Simply download JDK version(s) as zip file(s) from https://adoptopenjdk.net and extract it/them to the C:\lucee\ directory e.g. C:\lucee\jdk-11.0.11+9 or C:\lucee\jdk8u292-b10.

To switch them you can simply stop Lucee/Tomcat and rename the directories (old into C:\lucee\jdk_bak and the new into the default location C:\lucee\jdk). Then restart Lucee/Tomcat. Switching between Java versions like so feels the quickiest to me. If something goes wrong, you can always switch back in a matter of seconds by renaming it back without editing services or setenv.bat files.

This way I can switch safe even in production. If I notice a day or two that something is going wrong, I can simply rename the old version back.

Lucee.jar
Similarly I do it with Lucee.jar for Lucee upgrades. I have various Lucee-x.x.x.x.jar downloaded and located in Tomcats lib or lib/ext folder. I have them all deactivated by having the file extension named *.j–ar and only keep the .jar file extension of the Lucee version intact that I want to load/run.

Switching back and forth even in production is extremly quick. That is what I do when @Zackster comes here asking us to test release candidates on production :smiley:

But always make also a backup of your Lucee admin configurations first.

There is currently one known regression with this release

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

It has just been fixed in the 5.3.8.191-SNAPSHOT, we will be making a minor 5.3.8 stable release next week including this fix

1 Like

Another regression with this latest release.
https://luceeserver.atlassian.net/browse/LDEV-3622

Same here - experiencing both regressions unfortunately. Any ETA on that fixes update?

Hi @rd444, do you have a stacktrace from the Compile error that includes the “Caused by:” line? If so, can you please post to https://lucee.daemonite.io/t/compile-errors-in-5-3-8-189/8590? Thanks, Simon

@Simon_Goldschmidt - I don’t have a stack trace either, just the same new slew of Application.log messages a la the below. We are on AWS EC2s, but not seeing any evidence of any sort of disk access issues via all of their metric tools.

application.logERROR 01:29:18, 23 Jul, 2021http-nio-8888-exec-12"Class [kansas_city315.addyourshow_cfm$cf$g3] is invalid or doesn’t exist;Class [kansas_city315.addyourshow_cfm$cf$g3] is invalid or doesn’t exist;java.lang.ClassNotFoundException: Class [kansas_city315.addyourshow_cfm$cf$g3] is invalid or doesn’t exist

Just checking back here to see if there’s an update on the horizon as we’re back to having to restart every couple of days.

we are still working thru a few more regressions in 5.3.8, then we will have a new minor 5.3.8 release

that compile problem hasn’t be solved yet

1 Like

Hi @Zackster- is there any ETA on this compile fix / minor release?

5.3.8.201 has some me extra logging to diagnose this

Is there anything I can send you from there @Zackster? That’s what we’re running that’s still requiring periodic restarts.

We ran Debug-level Application log on 5.3.8.201 and found that each time this error occurred, it was preceded by a line like this:

"DEBUG","ajp-nio-127.0.0.1-8009-exec-3","08/12/2021","21:35:39","compile","load class from ClassLoader  [C:\Webroot\payment.cfm]"

and followed by a line like this:

"DEBUG","ajp-nio-127.0.0.1-8009-exec-3","08/12/2021","21:35:39","compile","load class from binary  [C:\Webroot\payment.cfm]"

For us, there are episodes when a bunch of scripts are loaded from “ClassLoader” and return a Compile error, but scripts are subsequently loaded from “binary” without an issue. Although there is a bit of activity in our Error logs, there doesn’t seem to be any issue that prevents our application from working as it should.

Details here: [LDEV-3622] - Lucee