Blog

Jon Clausen

October 03, 2022

Spread the word


Share your thoughts

There are times when code needs to be shipped in a compiled state. It might be for obfuscation or source protection, it might just because it runs faster that way, without the CFML server needing to compile templates at runtime. It's an excellent use case for production Docker images and code deploy pipelines.

If you are running your applications on Lucee, the bytcode compilation is a bit different than the one Adobe performs. In that case, your best option is to use the cfml-compiler module on Forgebox. The downside to Lucee's compilation is that it doesn't package an entire application to the target directory. Instead, Lucee will only compile and move .cfm and .cfc files it encounters, leaving all other files untouched. Because of this, it is best to make a copy of your source code and compile in-place so all application assets ( JS, CSS, images ) are co-located in the final package.

In build environments, it's often unecessary to go through the steps to install Commandbox other dependencies because Docker is usually readily available. We can use the presence of Docker to run one-off commands to perform steps like installing CommandBox dependencies:

docker run --rm -v $PWD:/app ortussolutions/commandbox /bin/bash -c "box install"

The above one-liner will perform a box install on the source code in your current working directory. Note the use of the --rm flag, which will remove the container after the script has finished. To compile Lucee source code in-place, overwriting the existing uncompiled templates, the command would like something like this:

docker run --rm -v $PWD:/app ortussolutions/commandbox /bin/bash -c "box install cfml-compiler && box cfcompile box cfcompile sourcePath=./ destPath=./ overwrite=true cfengine=lucee@5.3.9"

For Adobe Coldfusion source code, because it will also copy over non-CFML files, you can compile in to a separate directory without losing those assets. The process is a bit more complex, in which case, rather than passing in a single command, we will create a shell script which we can mount in and pass in to the command of the container. To do this, we'll create a file called compile-source.sh and place it in to a util folder above the root where we will be running our Docker commands:

#!/bin/bash
export CFUSION_HOME=/usr/local/lib/serverHome/WEB-INF/cfusion
export WEBINF=/usr/local/lib/serverHome/WEB-INF
export COMMANDBOX_HOME=/usr/local/lib/CommandBox
export CLASSES=$webroot/lib/java/*:$WEBINF/lib/*:$CFUSION_HOME/lib/*:$CFUSION_HOME/lib/updates/*:$WEBINF/lib/etc/*:$CFUSION_HOME/lib/axis2/*:$WEBINF/lib/oosdk/lib/*:$WEBINF/flex/jars/*:$WEBINF/cfform/jars/*:$CFUSION_HOME/jetty/lib/*:/usr/local/lib/serverHome/CFIDE/administrator/classes/*:/usr/local/lib/serverHome/CFIDE/classes/*:$CFUSION_HOME/jintegra/lib/*:$CFUSION_HOME/jintegra/*:$COMMANDBOX_HOME/lib/*

PATH=$PATH:$CFUSION_HOME/bin
export PATH

# Install some java libraries in to the classpath which are not present in the J2EE deployment:
apt update && apt install -y wget && \
cd /tmp && \
    wget --content-disposition https://search.maven.org/remotecontent?filepath=javax/servlet/javax.servlet-api/4.0.1/javax.servlet-api-4.0.1.jar && \
    wget --content-disposition https://search.maven.org/remotecontent?filepath=jetty/jsp-api/2.1-6.0.2/jsp-api-2.1-6.0.2.jar && \
    mv /tmp/*.jar /usr/local/lib/serverHome/WEB-INF/lib/ && cd /app

echo "Compiling source at $srcdir to $webroot"

# Compile our source in to the specified directory
# The use of --add-opens assures that all members of those named classes are accessible for reflection, if necessary
/opt/java/openjdk/bin/java --add-opens=java.base/java.nio=ALL-UNNAMED \
            --add-opens=java.base/java.lang=ALL-UNNAMED \
            --add-opens=java.base/sun.util.cldr=ALL-UNNAMED \
            --add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED \
            -cp $CLASSES -Dcoldfusion.classPath=$CFUSION_HOME/lib/updates,$CFUSION_HOME/lib \
            -Dcoldfusion.libPath=$CFUSION_HOME/lib \
            coldfusion.tools.CommandLineInvoker Compiler \
            -deploy -webinf $WEBINF -webroot $webroot -cfroot $CFUSION_HOME -srcdir $webroot -deploydir $deploydir

Note the two java JARs which we download and place in to the classpath, before running the compilation. These JARS are not present in the J2EE version of Adobe Coldfusion, which is what is used in the Docker containers.

Once our shell script has been saved, our command to compile ACF, using the ACF 2018 container code looks like this:

docker run --rm -v $PWD:/app -v $PWD/tmp:/tmp/src -v $PWD/../util/compile-source.sh:/usr/local/lib/compile-source.sh \
-e "webroot=/app" -e "srcdir=/app" -e "deploydir=/tmp/src" \
ortussolutions/commandbox:adobe2018 \
/usr/local/lib/compile-source.sh

With this command, we are mounting in our current working directory to the convention /app directory in the container. We are also mounting a folder named tmp which will be created by the container if it does not exist. Lastly, we mount in our compile-source.sh script and use it as the entrypoint for the container which then runs that script only, when the container comes online.

Due to the fact that many Open source libraries ( such as Coldbox ) support both Lucee and Adobe, you will want to run your code compilation before you run your box install. This is because there may be Java classes referenced, which are Lucee-only, which will throw errors when attempting to compile for Adobe Coldfusion, since those classes are not present.

This same command works on the Adobe 2021 container, as well, however you will need to install any cfpm modules referenced in your code in the compile-source.sh script.

By shipping your applications to production with compiled source code, you will notice a significant performance improvement - especially on application startup - since no compilation of your source code is necessary.

Add Your Comment

Recent Entries

Into the Box 2024 Last Early Bird Days!

Into the Box 2024 Last Early Bird Days!

Time is ticking, with less than 60 days remaining until the excitement of Into the Box 2024 unfolds! Don't let this golden opportunity slip away; our exclusive Early Bird Pricing is here for a limited time only, available until March 31st. Why wait? Secure your seat now and take advantage of this steal!

Maria Jose Herrera
Maria Jose Herrera
March 20, 2024
Ortus February Newsletter 2024

Ortus February Newsletter 2024

Welcome to Ortus Solutions’ monthly roundup, where we're thrilled to showcase cutting-edge advancements, product updates, and exciting events! Join us as we delve into the latest innovations shaping the future of technology.

Maria Jose Herrera
Maria Jose Herrera
March 06, 2024
Unveiling the Future of CFML Development - 3rd Round of Sessions

Unveiling the Future of CFML Development - 3rd Round of Sessions

Welcome back to our journey into the future of CFML development! As excitement continues to build for Into the Box 2024, we're thrilled to bring you the latest updates on what promises to be a transformative event. Continuing our blog post series, let's delve deeper into the third wave of session releases and discover the key surprises awaiting attendees. Learn More

Maria Jose Herrera
Maria Jose Herrera
March 01, 2024