We had a weird glitch this morning with our lucee app server, I wonder if this has hit anyone else or anyone has an ideas. We build our image from

ortussolutions/commandbox:jdk11-alpine

with lucee-light@5.3.9.133, the build pipeline downloads the lex extensions we use like s3, json, jdts, etc directly into

${BOX_SERVER_APP_SERVERHOMEDIRECTORY}/WEB-INF/lucee-server/deploy/

so they are warmed up and deployed, then each instance doesn't have to download the extensions from the lucee release server. This has been running basically fine like this for a couple years. The build that got deployed last night started throwing the error:

S3 uploadFormFile failed The OSGi Bundle with name [s3.extension] is not available in version [0.9.4.155-SNAPSHOT] locally (/app/server/WEB-INF/lucee-server/bundles) or from the update provider (<http://release.lucee.org>), the following versions are available locally [0.9.4.154, 0.9.4.154].

We didn't change what version of the s3 extension we use (0.9.4.154), or what version of lucee we use, it was just a code push. The only thing I can think that changed between docker builds is the base docker image, but even then I can't figure why that would make lucee v5.3.9.133 thinks it needs a different s3 extension version to run? This has happened twice before, in exactly the same way. The fix for the problem was to bump the s3 extension to the snapshot release 0.9.4.155-SNAPSHOT, then lucee was happy and working the same. Its a bit unsettling when this to issue happens, I've come to expect docker images to be very consistent, I wouldn't expect this type of compatibility issue unless I was changing the lucee server. Next steps is we're looking to change our build process from lucee-light to lucee regular, hoping the bundled extensions are more consistent, has anyone else run into this issue?

Check the web.cfm.xml if there's a specific version specified in the bundle. I've run into that issue recently, but not sure what caused it. I had to modify the file and just removed the required version information. I found this in a number of places in the file.

Interesting so that file is probably from the base ortussolutions/commandbox:jdk11-alpine image and not tied to which lucee engine is specified, I don't replace or override it in my dockerfile, maybe I should to keep it static... hmmmm

Try it on on a dev version of lucee from binary, if it works, it could be a commandbox issue. You could also reach out to brad, as commandbox is his baby.

i think you might be hitting this error, lucee bytecode hardwires the extension version which causes problems when you upgrade extensions, doing a pagePoolClear() per application should resolve it (aka recompile all your cfml code) https://luceeserver.atlassian.net/browse/LDEV-4187

@zackster Hmmmm so our docker build process is also precompile all of our applications' cfm/cfc source code with lucee's

createArchiveFromMapping()

into .lar files, so maybe as that ticket is showing, that compile step is hardwiring the extension version into the files?

the compile happens after it's configured tho?

the compile happens in the dockerfile, before the compile it has

ENV BOX_SERVER_APP_CFENGINE=lucee-light@5.3.9.133

the compile step is done with a

box task run build.cfc

execution

easiest is to try doing a pagePoolClear() and see if that solves the problem, then you know that's the problem

@zackster Tried pagePoolClear(), it wasn't the cause. I think I figured it out, Our build pipeline is executing

box task run

that calls lucee's createArchiveFromMapping() that compiles the cfm/cfc code into a lar, somehow that is embedding the extension dependancy (for s3 0.9.4.155-SNAPSHOT) from lucee v5.3.9.160 that is baked into the box cli into the lar archive/bytecode. This conflicted with the actual application server is running lucee v5.3.9.133 which needs and had s3 0.9.4.154

best/safest to use your actual configured live instance to compile (posted the same to the box channel)

admin action="compileMapping"

type="server"

password=request.SERVERADMINPASSWORD

virtual="/"

stoponerror="false";

@zackster I'd like to compile during the docker build phase, any suggestions on how to do that? It would be so handy if this was part of the server warmup, because we don't want to have each docker instance compile on first load

Copy over the compiled code to the choot before you create your custom img.

if it's a single context with lucee_enable_warmup, there is the new web.cfc (check jira) which could be used. I think i have already filed a enhancement about compiling as part of the warmup process