Clean updates of Lucee 7

dev support
1

Historically, we’ve found when updating the version of Lucee it’s better to clear a number of the lucee-server folders and just let it rebuild things on first start. We just found it avoided some corner case issues and gave us the closest to a “fresh” install. This is all part of our provisioning shell scripts.

In examining the changes from Lucee 5 to 7, it looks like we might want to purge the following folders when updating Lucee with a new JAR:

  • server/lucee-server/context/cache/
  • server/lucee-server/context/cfclasses/
  • server/lucee-server/context/dynclasses/
  • server/lucee-server/context/mvn/cache/
  • server/lucee-server/context/temp/
  • server/lucee-server/patches/
  • server/lucee-server/felix-cache/

Does this look right?

I realize that purging something like the mvn/cache folder could lead to new JARs being downloaded, but sort of files like that should probably happen anyway to be on the safe side (because sometimes when updating Lucee, we’re also updating the Java version, etc).

Does this still seem like the best safe practice? Are there any changes I should make?

Maybe @Zackster or @micstriit have input?

2

The felix-cache is the only one I purge, which is automatically regenerated / populated on startup

There’s a slight bug relating to that with updates, but otherwise Lucee self manages everything

cfclasses only needs a purge if we made a bytecode change

3

For our Lucee 5 provisioning scripts, I was purging these folders on updates:

And that’s always worked solidly. I can’t recall the exact reason we ended up purging all of these folders (other than server/lucee-server/felix-cache/), but I know I was running into issues every once and a while with weird side effects after updating.

All of these folders should get automatically rebuilt thought, right?

It would just seem to me that if we have updated our JDK, blowing these folders out would be useful to make sure everything re-compiles with the latest JDK. Even if Lucee should be handling things under the hood, bugs happen, so I’d rather start with as clean as slate as possible after updating.

The cost of Lucee having to rebuild stuff that maybe isn’t necessary, is a one time hit that is worth paying for to ensure you’re not dealing with some very weird corner case issues that ends up becoming terribly hard to track down. It also just confirms that every environment should be at the same place once Lucee starts up.

Thoughts?

4

Honestly, rather than all this dancing around, I’d be moving to a fresh deploy / provisioning each time?

Docker is great for this

7 deploys even quicker than 6 and builds / deployments should be reproducible

5

here my 3c for this (1c is late fee).

i get your point and i may would do the same in the past, we had some issues specially with “dynclasses”, but with Lucee 7 this really should not be necessary.
but what does not hurt…
if you have any concrete example of some issues causing this, let us know we will fix it.

in any case i would not delete " *server/lucee-server/context/mvn/cache/" this is a maven repository and it stores artifacts with versions and they are immutable and lucee always checks the checksum after downloading, so very unlikely you ever have a corrupt file in there and if you have, it will be removed.

6

A specific issue I’ve seen is when downgrading. For example, I was testing 7.1.0.204, but due to the mail issues I had to rollback to 7.0.4.34. However, even after purging the folders I was it seemed some of the extension/jars were left behind.

I’d like to really make sure I have a “clean” environment when I update, making sure that any old JARs are cleaned out just to reduce the likelihood of an old jar/extension being left behind that alters the behavior in a subtle way.

1 Like
7

This isn’t really a bug, it’s how Lucee handles required extensions. Each Lucee version defines a set of required extensions with a minimum version and installs them if they’re missing. For example, 7.1.0.204 requires the mail extension 1.1.0.6 and the FTP extension 1.0.0.5, while 7.0.4.34 requires neither, because mail and FTP were still part of the core in 7.0.

When you roll back from 7.1.0.204 to 7.0.4.34, Lucee doesn’t remove or downgrade anything. A requirement is only a minimum version, so if you already have the same or a newer version installed it stays, and an extension that isn’t required at all is never removed. So the mail and FTP extensions stay installed, along with the artifacts they brought in.

This has always been the case, and it’s the downside of the extensions bundled with Lucee. To get a clean environment after a rollback, remove or downgrade those extensions in the Lucee Administrator, or directly in .CFConfig.json. For full control, Lucee Light is the better choice: define exactly the extensions you want in .CFConfig.json, or install them through the deploy folder. The new recipe on downloading extensions covers both.

8

I’ve made it a habit in all the Lucee projects I work on to always set up my own .CFConfig.json that defines every extension I need, and I never install an extension any other way. Here’s an example:

{
  "extensions": [
    {
      "id": "CED6227E-0F49-6367-A68D21AACA6B07E8",
      "name": "Lucee Administrator"
    },
    {
      "id": "66E312DD-D083-27C0-64189D16753FD6F0",
      "name": "PDF Extension"
    },
    {
      "id": "8D7FB0DF-08BB-1589-FE3975678F07DB17",
      "name": "Compress Extension"
    },
    {
      "id": "37C61C0A-5D7E-4256-8572639BE0CF5838",
      "name": "ESAPI Extension"
    },
    {
      "id": "B737ABC4-D43F-4D91-8E8E973E37C40D1B",
      "name": "Image Extension",
      "version": "2.0.0.33",
      "resource": "${EXTENSION_PATH}/extensions/image-extension-2.0.0.33.lex"
    },
    {
      "id": "037A27FF-0B80-4CBA-B954BEBD790B460E",
      "name": "cfspreadsheet",
      "version": "3.0.4",
      "resource": "${EXTENSION_PATH}/extensions/cfspreadsheet-3.0.4.lex"
    },
    {
      "id": "7E673D15-D87C-41A6-8B5F1956528C605F",
      "name": "MySQL",
      "version": "9.3.0",
      "resource": "${EXTENSION_PATH}/extensions/com.mysql.cj-9.3.0.lex"
    },
    {
      "id": "E6759ABD-D91A-4E87-AC471C88A6A87185",
      "name": "Amazon Redshift JDBC Driver",
      "version": "2.2.8.0",
      "resource": "${EXTENSION_PATH}/extensions/redshift-jdbc-extension-2.2.8.0.lex"
    },
    {
      "id": "261114AC-7372-4CA8-BA7090895E01682D",
      "name": "EC2 Resource Extension",
      "version": "1.0.0.1",
      "resource": "${EXTENSION_PATH}/extensions/ec2-extension-1.0.0.1.lex"
    },
    {
      "id": "D6700FE4-E168-4512-9B95E1AE7784A3A5",
      "name": "AWS Kinesis Resource Extension",
      "version": "1.0.1.7",
      "resource": "${EXTENSION_PATH}/extensions/kinesis-extension-1.0.1.7.lex"
    }
  ]
}

This is from a project running on EC2 with Lucee 7.0. I list the extensions bundled with Lucee first, without a version, because anything missing from the list gets uninstalled. After those come my custom extensions, which I load from a local folder.

With this in place, when you downgrade, Lucee automatically uninstalls every extension that isn’t in the list.