Installing specific versions of extensions in Lucee 5.2.x

After doing some testing with older Lucee builds, it looks like Core bundles/extensions don’t get automatically updated on startup if a newer version exists (which is good), and if you specify a manifest style value in LUCEE_EXTENSIONS that includes the version number then there is also no risk of auto-updates happening to the extension.

It also seems like label and name aren’t both required, however including one of them does help identify which extension the configuration is for, e.g.;


On a related note, is there any configuration available for disabling specific extensions? For example there might be a number of extensions that ship in Lucee core that a particular application doesn’t need (Hibernate, certain database drviers, the Lucee Administrator, etc). Can we disable specific extensions, or do we need to remove the files from disk?

1 Like

@justincarter recently posted a nice little tutorial on spinning up memcached extensions in Docker :whale:

Is there a way to uninstall specific extensions using the same mechanism?

Are there any docs about what each of the environment variables do? I am still trying to install the extension as defined by the the LUCEE_EXTENSIONS variables but it doesn’t seem to be working on Lucee

Some docs and clarity outside the LAS team members would be nice.

docker compose example:

version: "3"
    image: ortussolutions/commandbox
      - ".:/app"
      - 8080
      - LUCEE_EXTENSIONS="16FF9B13-C595-4FA7-B87DED467B7E61A0;name=Memcached;version="
1 Like

With Docker it’s important that extensions are installed during the image build for a number of reasons (container startup time, removes the dependency on the extension server being contactable, consistent/repeatable builds, etc), so I’d avoid adding the LUCEE_EXTENSIONS environment variable to the Docker Compose file if possible since they are kind of run-time settings.

I think this is the most basic, working example that I can give as a starting point for installing Memcached, and then configuring it as a session store;


FROM lucee/lucee52:latest

# install extensions by prewarming lucee
ENV LUCEE_EXTENSIONS "16FF9B13-C595-4FA7-B87DED467B7E61A0;name=Memcached;version="
RUN /usr/local/tomcat/bin/

COPY www /var/www


  build: .
    - "/workbench/memcached/www:/var/www"
    - "8888:8888"
    - "memcached:memcached"
  image: memcached:alpine
    - "11211"

(Note: Your volume paths may vary, the above is just what works for me in my environment).


component { = "memcached";

	this.cache.connections["sessions"] = {
		class: "",
		bundleName: "memcached.extension",
		bundleVersion: "",
		storage: true,
		custom: {
			"servers": "memcached:11211"
		default: ""
	this.sessioncluster = true;
	this.sessionstorage  = "sessions";



<cfparam name="session.timestamp" default="#now()#">
<cfdump var="#session.timestamp#">

To test;

  1. Start the containers in the background with docker-compose up -d.
  2. Browse to the index of the app and a timestamp will be written to the session which will be stored in memcached.
  3. Restart just the Lucee container with docker-compose restart lucee
  4. Browse to the index of the app again and you should see that the timestamp remained the same, which means that the session was successfully persisted in memcached across Lucee restarts.

If you’re using CommandBox Docker images I don’t know the most efficient way of installing/prewarming Lucee there, there’s perhaps a command that will start and stop the server for you. I would start with barebones Lucee Docker images to prove it’s working, and then move back up the chain up from there.

Hope that helps :smiley:


This post makes reference to a spreadsheet tracking the state of all config options:

What do you have in your script? is it

 RUN rm -rf /opt/lucee/web/logs/ && \
   /usr/local/tomcat/bin/ start && \
   while [ ! -f "/opt/lucee/web/logs/application.log" ] ; do sleep 2; done && \
   /usr/local/tomcat/bin/ stop

Yep, you can see the source here:

1 Like

Hi @markdrew I just noticed your comment. I don’t know if you figured it out, but the env var LUCEE_EXTENSIONS is not what Lucee proper looks for. I believe that name is specifically something looked for in the official lucee image that gets passed through to an env var or JVM prop of the name Lucee is actually looking for which is either lucee-extensions (deprecated) or lucee.extensions

The CommandBox image doesn’t provide a passthrough env var called LUCEE_EXTENSIONS. We could, but I’m not sure what the point would be since it’s almost exactly named as the built in env var, just non-standard. With the CommandBox image, just provide the environment variable in the format Lucee itself is looking for and everything should work.

Also, FWIW, since these links are so hard to find, I’ll leave them here as well. Here’s the docs for that env var (which seriously needs some love since it doesn’t even cover specific versions!):

And here is the “living” Google Doc that lists all possible env vars and system props. The one in question is on line 5.

The Lucee settings that come from Java system properties are also supported as environment variables. From my original post above;

This means that the Java system property lucee.extensions can instead be specified as the environment variable LUCEE_EXTENSIONS, and the same should apply to all the other properties that are listed in the above spreadsheet :slight_smile:

Edit: just to clarify, the Lucee docker images don’t do anything special to find and pass through these environment variables as system properties, they are supported directly by Lucee and should work anywhere AFAIK.


We use

ENV LUCEE_EXTENSIONS "66e312dd-d083-27c0-64189d16753fd6f0;name=PDF;version=,99a4ef8d-f2fd-40c8-8fb8c2e67a4eeeb6;name=MSSQL;version=6.2.2.jre8"

In our Dockerfile and that seems to work, as once we’ve prewarmed saved the image then spun the image up, going to the extensions area shows these as up-to-date.

It would be really good if Lucee would either use ExtensionStore ID’s as you are doing or forgebox stubs, I think this would look better no?

ENV LUCEE_EXTENSIONS pdf@, memcached@

Since using the UUID is such a pain for admins etc that would look at a random docker file (like I have) :

FROM ortussolutions/commandbox

Prizes for anyone to know what extension that is :slight_smile:

At the end of the day, the point of this is to make configurations easily readable by humans.

In summary, add stub names for the existing extensions (store, since that is where they come from), if not found, look for them in

steps off soapbox

1 Like

Mine looks like

ENV LUCEE_EXTENSIONS "66e312dd-d083-27c0-64189d16753fd6f0;name=PDF;version=,99a4ef8d-f2fd-40c8-8fb8c2e67a4eeeb6;name=MSSQL;version=6.2.2.jre8"

And that appears to install, whilst I can at least see what it’s going to do…

I get you, I see what it’s going to do, but it’s an abusive way to do it for the poor sys admin that I am going to hand off the docker file to.

And then I tell him about the box.json file that also downloads dependencies etc. I know you can read it but there is usually a chain of people that need to know this.

(I wasn’t having a go at you sir, just the implementation)

Micha explained above the reason for the current implementation is that it matches the OSGi syntax that is used in the manifest files for installing extensions;


It’s not the nicest thing to read but the name and/or label does make it human readable, and I’m ok with it at least being consistent with what is already used in the manifests.

That said, I’d be happy to see a new identifier that wasn’t a UUID if Micha thinks that’s feasible to support :slight_smile:


FWIW, when using the CommandBox Lucee images, here’s the approach we take to bypass using the environment variables, but still install the extensions we need:

1 Like

Awesome project @mjclemente!

by setting “lucee.extensions.install” to false, the extension defined in the manifest not get installed, that way only extension defined with env variable get installed

Such a nicer solution

Circling back to your initial post here; just out of curiosity, does the version of the Memcached plugin cause an issue for you?

Or was that example purely for the sake of example?


1 Like