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

Ortus Black Friday Deals are here!

Ortus Black Friday Deals are here!

Make 2023, the year you finally start modernizing your CFML projects with our Black Friday deals!

Don't waste any more time trying to find solutions, we got everything you need to rock your projects and learn new skills that will save you time and money while delivering a quality service. 

From Nov 25th to Dec 1st

Maria Jose Herrera
Maria Jose Herrera
November 25, 2022
Call For Speakers Open for Into The Box 2023

Call For Speakers Open for Into The Box 2023

We are very excited that the Into The Box conference is coming back to the Houston area and FINALLY on our normal schedule of May of 2023. Registration is now officially open and call for papers is now open as well. We are also extremely excited that this will be our 10 year anniversary for the Into The Box Conference. So we will defintely go all out!

  • Full 2-day conference with over 30 different technology topics
  • An additional full day of hands-on training available for a veritable 3 days of awesomeness
  • A warm and sunny city of The Woodlands, Texas
  • When: May 17-19 of 2023
  • Modernize Your Skillz
  • Party with our live Mariachi Band!

Luis Majano
Luis Majano
November 11, 2022
New Patreon Perk: Ortus Software Craftsmanship Book Club

New Patreon Perk: Ortus Software Craftsmanship Book Club

What is the Software Craftsmanship Book Club?

Its a place for CFML Community members can get together, discuss and debate the thoughts, ideas, best practices outlined by a series of books focusing on increasing Software Developers efficiency, productivity and pride. It will be relaxed but educational environment, where we can learn from each other, and grow as a community.

 

Ortus Software Craftsmanship Book Club

Maria Jose Herrera
Maria Jose Herrera
November 09, 2022