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

Protect Your Data with Proactive Database Security Management

Protect Your Data with Proactive Database Security Management

In today’s digital age, data is among the most valuable assets for businesses. It powers decision-making, customer engagement, and operational efficiency. However, as data volumes grow, so do the risks associated with managing it. Ensuring database security and compliance is no longer optional—it’s a necessity.


The Evolving Landscape of Database Security

Modern databases face a myriad of challenges, from increasingly sophisticated cyber threats to strin...

Cristobal Escobar
Cristobal Escobar
December 06, 2024
The Experts Driving BoxLang: The Team Behind the Revolution

The Experts Driving BoxLang: The Team Behind the Revolution

Introduction

BoxLang is not just another programming language; it’s a revolutionary step forward for JVM environments. But who are the minds behind this innovation? Meet the talented team of architects, developers, and engineers who have combined decades of experience to create BoxLang—a language built for scalability, performance, and efficiency. Let’s explore their ex...

Cristobal Escobar
Cristobal Escobar
December 04, 2024
Why BoxLang is the Modern Software Development Evolution You’ve Been Waiting For?

Why BoxLang is the Modern Software Development Evolution You’ve Been Waiting For?

In today’s software landscape, developers need tools that deliver flexibility, efficiency, and modernization. With decades of open-source expertise, Ortus Solutions introduces BoxLang—our most ambitious project yet. Built for the JVM, BoxLang integrates seamlessly with Java, offering powerful features for scalable, high-performance web applications. Fully compatible with CFML, it ensures a smooth transition and expanded capabilities for existing projects.

Maria Jose Herrera
Maria Jose Herrera
December 04, 2024