OK I am utterly bemused by the Lucee on-the-fly extension loading / pre-warm carry on now. I just pruned all my cached images, rebuild my container from

lucee/lucee:5.3.9.173-nginx

, started it, before running ANY code, I disconnected from the outside world completely and then ran some code using

encodeForHtml

and

cfdocument

and both tests passed fine. No extensions needed to download, apparently.

coz you are using the far jar / full version which bundles those extensions?

😐

that was only for things like jdbc connections which specify a specfic bundle version which isn't bundled

This is from the situation I was chasing a month or so ago:

The log entry says:

Copy code

In the OSGi Bundle with the name [esapi.extension] and the version [2.2.4.7] was no class with name [org.lucee.extension.esapi.functions.EncodeForHTML] found

Not sure what that might mean if it was presented in coherent English.

Also this gets logged:

Copy code

org.osgi.framework.BundleException: Unable to resolve esapi.extension [70](R 70.0): missing requirement [esapi.extension [70](R 70.0)]

This is logged when Lucee is trying to execute a CFML statement that uses

encodeForHtml

. We've opened ext.lucee.org on our firewall, and at least now the extensions page in Lucee admin doesn't error-out, but it claims the ESAPI extension is installed! (note it's still saying it can't reach the update server in the next panel down, but I suspect this is because the "Installed" stuff is hitting ext.lucee.org, and the "Not installed" is hitting updates.lucee.org or downloads.lucee.org or something, which I've only just found out about, and have not opened the firewall for). But. If the ESAPI extension is installed... why am I getting that

Copy code

In the OSGi Bundle with the name [esapi.extension] and the version [2.2.4.7] was no class with name [org.lucee.extension.esapi.functions.EncodeForHTML] found

Error? This is in a Docker container built from the

lucee/lucee:5.3.9.173-nginx

image.

looks like it's just an old version which had issues and was subsequently fixed https://luceeserver.atlassian.net/browse/LDEV-4132

Yeah that's a pretty standard "not enough info to be coherent" Zac special, that ticket.

old version extension, known issue, subsequently fixed

And that bug only manifests when Lucee can't phone home? We don't have the same issue on our more "open" servers, and they're also running the 2.2.4.7 ESAPI extension. The weird (or is it? Dunno) thing is that sometimes on the problematic box,

encodeForHtml

seems to work OK. And continues to for a while. But then eventually it always goes splat again (and by "eventually" I mean "a few minutes... maybe more than 10, fewer than 30) Boxes are identical (for all intents and purposes) and the docker container is identical in both cases. Firewall rules on the host VPS is the only diff.

That release had a bug, it was fixed, you're using an old release? What's your expected satisfactory solution?

The bug fix is possibly fine. I can't comment in an informed way as the ticket is a mess and doesn't detail what the problem is and why; what the findings were; and what the fix was. This should be the baseline for any ticket accepted into your system. The resolution to my situation is subpar from my POV because of the poor comms on the ticket, no explanation as to why this problem never happened on one set of servers and always happens on another set of seemingly identical servers (configwise, at least). I now have to meddle with production servers that have no issue at all with this purported bug, because some other servers do have manifestation of this bug (and we need the build of the servers to be the same in this situation). Also almost every time I have to touch Lucee versions it seems to swap one set of "unexpected behaviour" with another set of "unexpected behaviour"; I have no reason to think it won't be a similar experience upgrading this extension as well (although smaller surface area, sure). This is partly down to a situation of our own (historic) manufacture as our app test coverage is so poor; but this only means we can't predict the new issues Lucee upgrades throw at us; rather than there not being any issues. And it all causes me work that doesn't forward our bottom line one jot. That's why I don't think it's a satisfactory resolution. But it is what it is. [shrug]