Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
To use CFConfig, you can install it into CommandBox easily like so.
Now that you've got the tool installed you can dig into the command help to see where to go from there. Here's a quick overview of some of the commands. Run the built-in command help for more info on each one.
These commands will work on any CF engine and if you run them from the root of CommandBox server they will "just work" as it will "find" the server for you. To run these commands against another type of server, you'd need to specify a folder path for the "from" or "to" parameters that pointed to the server home directories.
CFConfig gives you the ability to manage almost every setting that shows up in the web administrator, but instead of logging into a web interface, you can manage it from the command line by hand or as part of a scripted server setup. You can seamlessly transfer config for all the following:
CF Mappings
Datasources
Mail servers
Request, session, or application timeouts
Licensing information (for Adobe)
Passwords
Template caching settings
Basically any settings in the web-based administrator
CFConfig will work on any CF server regardless of how it was installed. Since it interacts directly with the config files, the server doesn't need to be running. Heck, the server doesn't even need to be installed yet! CFConfig can be used to write out config files before you even start a CommandBox server for the first time.
But it's not just for CommandBox servers. All you need is the folder path to the CF home in your server installation and you can point the CFConfig library at it. This means CFConfig can be used for syncing config across existing servers, standing up docker containers, or provisioning Vagrant VMs.
CFConfig interfaces directly with the XML and property files used by your CF engine to store its configuration. It takes care of translating the config properly so you use the same commands regardless of what engine you're managing the config for. The tool will try hard to figure out the version of ColdFusion or Lucee that you have installed, and there are hints you can give it as well. Both ACF and Lucee also have settings to monitor the config files for changes, so you don't even need to restart the server to pick up your changes.
CFConfig exists in two parts:
A service layer for reading, writing, and storing configuration for all CF engines.
A set of scriptable commands built on top of CommandBox CLI.
The heart of CFConfig is a standalone module that provides a set of models and services for interacting with configuration files for all CF engines. This library allows for reading, writing, storing, and diffing configuration. This is an underlying service layer meant to have other tools built on top of it.
The CFConfig services do not require CommandBox but can be used on their own and provide a nice, fluent API for managing configs. They do not use RDS and don't need the server to be running. The services just need access to the installation folder for a server to locate its config files.
Generic JSON storage of any CF engine's settings
Engine-specific mappings for all major engines to convert their config to and from the generic JSON format
Export config from a server as a backup
Import config to a server to speed/automate setup
Copy config from one server to another. Servers could be different engines–i.e., copy config from Adobe CF11 to Lucee 5.
Merge config from multiple servers together. Ex: combine several Lucee web contexts into a single config (mappings, datasources, etc.)
The CLI portion of CFConfig wraps up the services layer into a CommandBox module that provides command line access to all the features above, but from your native OS shell, bash scripts, automations, or Docker/Vagrant/Heroku provisioners.
The CFConfig CLI also has a deep integration with CommandBox servers, making it very easy to manage their configuration.
Provides a native CLI tool for managing server configuration
Scriptable for automated server setup
Provides complete command help built-in
Tight integration with CommandBox servers
Welcome to the CFConfig Manual. CFConfig is a project aimed at helping server admins and developers alike manage the configuration of their favorite CF engine.
And constructed with the following guidelines:
Breaking backward compatibility bumps the major (and resets the minor and patch)
New additions without breaking backward compatibility bumps the minor (and resets the patch)
Bug fixes and misc changes bumps the patch
Copyright by Ortus Solutions, Corp
Info The CFConfig Websites, Documentation, logo and content have a separate license and they are a separate entity.
We all make mistakes from time to time :) So why not let us know about it and help us out? We also love pull requests, so please star us and fork us:
Custom Development
Professional Support & Mentoring
Training
Server Tuning
Security Hardening
Code Reviews
Source Code:
Because of His grace, this project exists. If you don't like this, don't read it; it's not for you.
"Therefore being justified by faith, we have peace with God through our Lord Jesus Christ: By whom also we have access by faith into this grace wherein we stand, and rejoice in hope of the glory of God." Romans 5:5
Brad's CommandBox Snake high score is 141.
Luis has a passion for Jesus, tennis, golf, volleyball and anything electronic. Random Author Facts:
He played volleyball in the Salvadorean National Team at the tender age of 17
The Lord of the Rings and The Hobbit is something he reads every 5 years. (Geek!)
His first ever computer was a Texas Instrument TI-86 that his parents gave him in 1986. After some time digesting his very first BASIC book, he had written his own tic-tac-toe game at the age of 9. (Extra geek!)
He has a geek love for circuits, microcontrollers and overall embedded systems.
He has of late (during old age) become a fan of running and bike riding with his family.
Keep Jesus number one in your life and in your heart. I did and it changed my life from desolation, defeat and failure to an abundant life full of love, thankfulness, joy and overwhelming peace. As this world breathes failure and fear upon any life, Jesus brings power, love and a sound mind to everybody!
“Trust in the LORD with all your heart, and do not lean on your own understanding.” – Proverbs 3:5
Jorge Reyes - ColdBox Aficionado
CFConfig is maintained under the guidelines as much as possible. Releases will be numbered in the following format:
CFConfig is open source and bound to the
The CFConfig help and discussion group can be found here:
CFConfig is professional open-source software backed by offering services like:
Official Site:
Bug Tracker:
Twitter:
Facebook:
Google+:
Vimeo Channel: (as well as older videos at )
Brad grew up in southern Missouri where he systematically disassembled every toy he ever owned which occasionally led to unintentional shock therapy (TVs hold charge long after they've been unplugged, you know) After high school he majored in Computer Science with a music minor at (Olathe, KS). Today he lives in Kansas City with his wife and three girls where he still disassembles most of his belongings (including automobiles) just with a slightly higher success rate of putting them back together again.) Brad enjoys church, all sorts of international food, and the great outdoors.
Brad has been programming CFML for 12+ years and has used every version of CF since 4.5. He first fell in love with ColdFusion as a way to easily connect a database to his website for dynamic pages. Brad blogs at and likes to work on solder-at-home digital and analog circuits with his daughter as well as building projects with Arduino-based microcontrollers.
Luis Majano is a Computer Engineer with over 15 years of software development and systems architecture experience. He was born in in the late 70’s, during a period of economical instability and civil war. He lived in El Salvador until 1995 and then moved to Miami, Florida where he completed his Bachelors of Science in Computer Engineering at . Luis resides in Houston, Texas with his beautiful wife Veronica, baby girl Alexia and baby boy Lucas!
He is the CEO of , a consulting firm specializing in web development, ColdFusion (CFML), Java development and all open source professional services under the ColdBox and ContentBox stack. He is the creator of ColdBox, ContentBox, WireBox, MockBox, LogBox and anything “BOX”, and contributes to many open source ColdFusion projects. He is also the Adobe ColdFusion user group manager for the . You can read his blog at
CFConfig must determine the server(s) on which to operate, which will either be a web context or a server context. CFConfig will determine the server as follows:
By default, when the to
or from
parameters are not present, CFConfig will use the current working directory, assuming it is the web root for an Embedded CommandBox Server (see below).
You provide a file path to the server home by using the to
and/or from
parameters.
The folder containing the lucee-web.xml.cfm
file. An example would be:
Path to the lucee-server
folder containing the /context/lucee-server.xml
file. An example would be:
The cfusion
folder that contains the lib/neo-runtime.xml
file. An example would be:
Just provide the path to the JSON file. This is auto-detected if the path ends in .json
. An example would be:
Every command with a to
and/or from
parameter also has a matching toFormat
and/or fromFormat
parameter. In most cases, you don't need to provide this. If you are pointing to an existing CommandBox server, or typical server installation, CFConfig will examine the files in the CF home to determine what engine and version it is. However, if you are writing files to an empty or non-existent directory, you'll need to tell CFConfig what format to write them in.
Format is specified as engine@version
where:
engine
is the name of the CF engine.
version
is a semantic version number representing the engine version.
Possible engine values are:
luceeWeb - Lucee web context.
luceeServer - Lucee server context (Default for Lucee servers).
adobe - Adobe server.
railoWeb - Railo web context.
railoServer - Railo server context.
Here are some examples of server formats:
adobe@10
adobe@11.0.10
luceeServer@5
luceeWeb@4.5
If you run CFConfig from the web root of a CommandBox embedded server, you do not need to specify the from
or to
parameters to reference it, and CFConfig will automatically default to the luceeServer
format, which operates on the server context. If you wish to interact with the web context (which has little distinction in a CommandBox server since there's only one web context per server), you will need to provide the explicit luceeWeb
format by using either the toFormat
or fromFormat
parameters.
This example assumes you are running CFConfig from the web root of an embedded server:
When using ModCFML, Lucee can have more than one web context. When using the fromFormat
or toFormat
of luceeWeb
, you will be interacting with the Lucee web context associated with the default web root. To interact with a specific Lucee web context, specify the web root in the format name like so:
You provide the name of a previously-started CommandBox server, using to
and/or from
parameters (see ).
CFConfig covers most of the common settings you'll find in Adobe and Lucee servers. This includes datasources, CF Mappings, Lucee caches, mail servers, logging settings, debugging settings, event gateways (Adobe), scheduled tasks (Adobe), and custom tag paths.
Here's an overview of what's supported.
Lucee 5.x
Lucee 4.x
Adobe CF 2023
Adobe CF 2021
Adobe CF 2018
Adobe CF 2016
Adobe CF 11
Adobe CF 10
Adobe CF 9
Railo 4.x
The majority of code examples in this book are done in cfscript
.
Flash, Flex, ColdFusion, and Adobe are registered trademarks and copyrights of Adobe Systems, Inc. Railo is a trademark and copyright of Railo Technologies, GmbH. Lucee is a trademark and copyright of Lucee Association Switzerland.
The information in this book is distributed “as is”, without warranty. The author and Ortus Solutions, Corp shall not have any liability to any person or entity with respect to loss or damage caused or alleged to be caused directly or indirectly by the content of this training book, software and resources described in it.
Shalom now cares for over 80 children in El Salvador, from newborns to 18 years old. They receive shelter, clothing, food, medical care, education and life skills training in a Christian environment. The home is supported by a child sponsorship program.
We have personally supported Shalom since 2006; it is a place of blessing for many children in El Salvador that either have no families or have been abandoned. This is good earth to seed and plant.
If you find a setting or feature which is not supported, please send a pull request. If you don't have time for a pull request, please so we can track remaining features.
If there is an engine/version or specific setting that's very important to you, Ortus is happy to have sponsored features. Please if you'd like to sponsor a feature.
The source code for this book is hosted in GitHub: . You can freely contribute to it and submit pull requests. The contents of this book is copyright by and cannot be altered or reproduced without author's consent. All content is provided "As-Is" and can be freely distributed.
We highly encourage contribution to this book and our open source software. The source code for this book can be found in our where you can submit pull requests.
15% of the proceeds of this book will go to charity to support orphaned kids in El Salvador - . So please donate and purchase the printed version of this book, every book sold can help a child for almost 2 months.
Shalom Children’s Home () is one of the ministries that is dear to our hearts located in El Salvador. During the 12-year civil war that ended in 1990, many children were left orphaned or abandoned by parents who fled El Salvador. The Benners saw the need to help these children and received 13 children in 1982. Little by little, more children came on their own, churches and the government brought children to them for care, and the Shalom Children’s Home was founded.
Here's an overview of all the commands available to the CFConfig CLI. There are sub-pages for each of these commands with additional details.
cfconfig export
Extracts all configuration from a server to a location of your choice.
cfconfig import
Imports all configuration from a location of your choice into a server. Like export
, but spelled different.
cfconfig transfer
Moves all configuration from a location of your choice to another location of your choice. Like import
and export
but pronounced different.
cfconfig diff
Shows a diff of every setting that's different between two servers or a server and a JSON file.
cfconfig set
Sets or overwrites a single setting on a server.
cfconfig show
Views a single setting on a server.
cfconfig datasource list
List all datasources.
cfconfig datasource save
Add or update a datasource by name
cfconfig datasource delete
Remove a datasource by name.
cfconfig cfmapping list
List all CF mappings
cfconfig cfmapping save
Add or update a CF mapping by virtual path.
cfconfig cfmapping delete
Remove a CF mapping by virtual path.
cfconfig cache list
List all caches in a Lucee/Railo server.
cfconfig cache save
Add or update a cache by name.
cfconfig cache delete
Remove a cache by name.
cfconfig mailserver list
List all mail servers on a server.
cfconfig mailserver save
Add or update a mail server by host.
cfconfig mailserver delete
Delete a mail server by host.
cfconfig customtagpath list
List all Custom Tag paths
cfconfig customtagpath save
Save a Custom Tag path
cfconfig customtagpath delete
Delete a Custom Tag path
cfconfig eventgatewayconfig list
List all Event Gateway Configurations
cfconfig eventgatewayconfig save
Add or update an Event Gateway Configuration
cfconfig eventgatewayconfig delete
Delete an Event Gateway Configuration
cfconfig eventgatewayinstance list
List all Event Gateway Instances
cfconfig eventgatewayinstance save
Add or update an Event Gateway Instance
cfconfig eventgatewayinstance delete
Delete an Event Gateway Instance
cfconfig logger list
List all Lucee Loggers
cfconfig logger save
Add or update a Lucee Logger
cfconfig logger delete
Delete a Lucee Logger
cfconfig task list
List all Scheduled Tasks
cfconfig task save
Add or update a Scheduled Task
cfconfig task delete
Delete a Scheduled Task
The CFConfig CLI lives on ForgeBox and can be installed into CommandBox with the following command:
If you do not have CommandBox installed, have no fear! CommandBox is a single binary that will run on Mac, Linux, or Windows. Please visit our CommandBox docs and you'll have it installed in a jiffy.
CFConfig is under active development and changing on a regular basis. To make sure you have the latest version installed, you can simply cd
into the CFML home directory of your CommandBox install and use the regular package update
command. This will pull in minor and patch updates but not major version changes.
If you have a pre-release version of CFConfig or need to upgrade to a new major version, use this command:
The only requirement for the CFConfig CLI is 3.6.0 or higher.
Export configuration from a server. If you don't specify a to
, we look for a CommandBox server using the current working directory. Only rely on this if you have a single CommandBox server running in the current directory.
All the same rules for engine format and version apply.
The version number can be left off toFormat
and fromFormat
when reading or writing to a CFConfig JSON file or a CommandBox server since we already know the version. If you don't specify a Lucee web or Server context, we default to server. Use a format of "luceeWeb" to switch.
In some situations you might need to alter the data being imported such as with Scheduled Tasks that you might not want to run on the target server. Adding the --pauseTasks
flag will import the scheduled tasks in the paused state.
You can customize what config settings are transferred with the includeList
and excludeList
params. If at least one include pattern is provided, only matching settings will be included. Nested keys such as datasources.myDSN
or mailservers[1]
can be used. You may also use basic wildcards in your pattern. A single *
will match any number of chars inside a key name. A double **
will match any number of nested keys.
Use the append
parameter to merge incoming data with any data already present. For example, if a server already has one datasource defined, and you import a JSON file with 2 more unique datasources, the --append
flag will not remove the pre-existing one.
If you usually replace sensitive or volatile information in a JSON export with env var expansions like ${DB_PASSWORD},
you can do this automatically my supplying one or more replace mappings. The key is a regular expression to match a key in the format of datasources.myDSN.password
and the value is the name of the env var to use. The values will be written to a .env
file in the current working directory. You can override this path with the dotenvFile
param, or pass an empty string to disable it from being written.
As the value is a regular expression, you can use backreferences like \1
in your env var to make them dynamic.
This example would create env vars such as DB_MYDSN_PASSWORD
where MYDSN
is your actual datasource name.
Any valid regex is possible for some clever replacements. This example would create env vars such as DB_MYDSN_PORT
, DB_MYDSN_HOST
, and DB_MDSN_DATABASE
To avoid having to pass these replacements every time you transfer your config, you can set then as a global setting for the commandbox-cfconfig
module.
The CommandBox CLI module will automatically register several interceptors that listen for server starts and stops. This allows you to automate your configuration without needing to manually load settings.
This functionality only applies to servers that are started in CommandBox. Examples would be using CommandBox for local development, deploying our Docker images or Heroku buildpacks.
You can use the CFConfig commands to manually import/export configuration on 'standard' CF installs, but these automatic interceptors here don't apply.
-- Import config automatically when the server starts
-- Optionally export config when the server stops
Every time a server starts, CFConfig will load configuration into your server by convention. For Lucee servers, settings go in the server context by default. Since each CommandBox Lucee server only has a single web context, the differentiation is mostly moot.
CFConfig will attempt to locate a JSON file containing exported server configuration. If it finds a JSON file, it will import it into the starting server as it comes up.
Here are the locations CFConfig will look for a JSON file and the order it will look for them in. After CFConfig files a JSON file in one location, it stops looking.
If an environment variable exists with the name CFConfigFile
, CFConfigWeb
, or CFConfigServer
it will be used as an absolute path to the JSON file or a relative path in relation to the web root. An example of setting this in Windows would be:
And on Unix...
Note: CommandBox won't pick up new environment variables in Windows until you close and reopen the shell.
It's not necessary to use cfconfigfile
and cfconfigsever
at the same time since they do the same thing. They are both provided for consistency. If you use both, they will all be imported!
Technically, you can also use one of the following env vars to do the same thing since CommandBox supports a generic syntax to override any server.json
property, but given the options above, it's not necessary to use these unless you want to or specifically want to override the settings in the server.json
.
server.json
propertiesIf there is a CFConfig
property in your server.json
file, it will be used to help control how your JSON configs are imported. All JSON file paths can be absolute or relative paths from the folder the server.json
lives in.
Note, you would never need to use all the properties above at the same time. The two top level ones are only supported for backwards compatibility. For an Adobe server, or a Lucee server in which you only care about importing settings into the server context, you can just use cfconfig.file
. For a Lucee server in which you want to import settings into the server AND web context, you can use cfconfig.server
and cfconfig.web
.
If you are using CommandBox's ModCFML support with Lucee, there can be a different set of settings for each Lucee web context. By default, all "web" settings will load into the web context that corresponds with the default CommandBox web root for the server. You can specify a JSON file for each web context in your server.json
like so:
The path to the web root as Lucee sees it is appended to the web
key after a hyphen (-
). CFConfig will pre-emptively create the web context folders based on the hash of the web root.
Since there are several overlapping conventions, it's possible to have more than one JSON file. For example, you could have a cfconfigfile
environment variable set as well as a cfconfig.file
key in your server.json
. In this case, BOTH JSON files will be imported. When there are two more JSON files being imported into the same web or server context, the first file will be an overwrite as usual and all subsequent files will be imported in "append" mode so they add to the settings in the previous file.
.cfconfig.json
File in Webrootif and ONLY IF no other settings (env vars, or server.json
properties) are found to specify a JSON file to import, CFConfig will look for the following files in the web root by convention.
.cfconfig.json
- Use this for Adobe or for Lucee's server context
.cfconfig-web.json
Use this for the Lucee web context
.cfconfig-server.json
Use this for the Lucee server context (same as .cfconfig.json
)
If the only convention file found for an Adobe server is .cfconfig-web.json
or .cfconfig-server.json
, it will still be used but just imported into Adobe's single context.
If you don't want to have a full JSON file, but just want to set some ad-hoc settings, you can do this via environment variables. These will load regardless of whether a JSON file was imported so it gives you a chance to override specifics like passwords. Environment variables are also perfect for cloud environments and Docker images.
When a server starts up, all environment variables will be looped over, and all the ones that start with cfconfig_
will be used. The naming format is cfconfig_xxx
where xxx
is the name of a valid config item such as adminPassword
or requestTimeout
.
Here's an example of what setting that up on Windows might look like:
And on Unix...
Now, every time a CommandBox server is started on this machine, that password will be loaded in, even if a previous JSON import had another password.
If you want to target the web context for your settings, you can use the syntax cfconfig_web_xxx
like so:
As a safety precaution, any time an adminPassword
setting is present in an auto-imported JSON file or a cfconfig_adminPassword
environment variable is set on a Lucee server, the server start interceptor will set that password into the web context as well as the default server context. This is to prevent a production server getting deployed with no password on the web context.
This only applies to the auto server start interceptors documented on this page. if you manually run a cfconfig import
or cfconfig set
command, it's up to you to also set things like passwords into the server and web contexts.
On both Lucee and Adobe servers, when the server profile is set to production
, CFConfig will not allow your sever to start with an empty password or with the Adobe default password of commandbox
. If any of those scenarios are detection in a production
profile, CFConfig will set a random password and output it in the verbose console logs for you to refer to later.
You can diff any two locations, meaning two servers, two JSON files, a server and a JSON file, etc.
You can even filter what config settings you see:
The cfconfig diff
commandbox has the ability to export HTML and PDF files. The contents of the report will exactly match what displays in the CLI. So any flags you apply such as --toOnly
will also filter the report output. This can be handy for historical purposes or just to get the data into a format that's easier to read than the CLI.
To generate an HTML report:
To generate a PDF report:
You can generate both HTML and PDF at the same time if you like. If you don't provide a filename, one is created for you with the following format:
The report directory is also created for you if it doesn't exist.
Remember, you can get funky and generate clever report names on the fly such as:
This would give you a name like Daily-Report-Thursday.pdf
! Existing files are overwritten.
If you are keeping your CF configuration in source control via a local JSON file, you may wish for the JSON file to automatically "track" your CF engine's settings. Otherwise, any changes you make to your CF setting in the web administrator will be lost the next time you start your server and your JSON config is imported again.
To enable this feature, add a global config setting in CommandBox like so:
The setting above defaults to off. You need to opt in to this behavior.
Every time a server does a graceful shutdown via the server stop
command, a suitable JSON file will be searched for using the same criteria used by the server start interceptor. If a JSON file is found, the current engine's config will be exported into it.
Lucee’s server and web contexts will export into the matching JSON files, if they exist. If there is more than one JSON file declared for a given context, the first will be used.
This ensures that any changes you make in the CF admin will be reflected back in your JSON file so you can commit it and share it with your coworkers. Please note, stopping a server from your system tray does not currently fire the server stop interceptors.
If you want to make temporary changes to your CF settings that you don't want to commit, use your source control to revert the JSON back, or turn the setting back off like so:
CFConfig supports over 200 individual config items. Here's the list of settings that CFConfig can manage
Note, this command requires named parameters.
You can actually use CFConfig set to manage the static contents of a JSON export. The JSON file is, after all, just another location you can read from or write to.
The cfconfig set
and cfconfig show
commands work the same as package set/show
in that you can use "deep" keys to access nested properties.
Keep in mind that examples such as the last line above can create invalid config if you don't already have a datasource called myDSN
. If you're needing to create new complex objects, or you're not sure if they will exist, use the other CFConfig namespaces like cfconfig datasource save
which will ensure complete settings are saved.
There are three commands to manage datasources.
To receive the data back as JSON, use the --JSON
flag.
Add a new datasource or update an existing datasource. Existing datasources will be matched based on the name. Valid dbdriver options are
MSSQL -- SQL Server driver
MSSQL2 -- jTDS driver
PostgreSql
Oracle
Other -- Custom JDBC URL
MySQL
Identify the datasource uniquely by the name.
Transfer configuration from one location/server to another. If you don't specify a from or to, we look for a CommandBox server using the current working directory. Only rely on this if you have a single CommandBox server running in the current directory. You must specify at least a from
or a to
.
Note the two servers do not need to be the same kind. CFConfig will translate the config for you.
All the same rules for engine format and version apply.
The version number can be left off toFormat
and fromFormat
when reading or writing to a CFConfig JSON file or a CommandBox server since we already know the version. If you don't specify a Lucee web or Server context, we default to server. Use a format of luceeWeb
to switch.
You can customize what config settings are transferred with the includeList
and excludeList
params. If at least one include pattern is provided, only matching settings will be included. Nested keys such as datasources.myDSN
or mailservers[1]
can be used. You may also use basic wildcards in your pattern. A single *
will match any number of chars inside a key name. A double **
will match any number of nested keys.
Use the append
parameter to merge incoming data with any data already present. For example, if a server already has one datasource defined, and you import a JSON file with 2 more unique datasources, the --append
flag will not remove the pre-existing one.
If you usually replace sensitive or volatile information in a JSON export with env var expansions like ${DB_PASSWORD},
you can do this automatically my supplying one or more replace mappings. The key is a regular expression to match a key in the format of datasources.myDSN.password
and the value is the name of the env var to use. The values will be written to a .env
file in the current working directory. You can override this path with the dotenvFile
param, or pass an empty string to disable it from being written.
As the value is a regular expression, you can use backreferences like \1
in your env var to make them dynamic.
This example would create env vars such as DB_MYDSN_PASSWORD
where MYDSN
is your actual datasource name.
Any valid regex is possible for some clever replacements. This example would create env vars such as DB_MYDSN_PORT
, DB_MYDSN_HOST
, and DB_MDSN_DATABASE
To avoid having to pass these replacements every time you transfer your config, you can set then as a global setting for the commandbox-cfconfig
module.
Import configuration to a server. If you don't specify a to
, we look for a CommandBox server using the current working directory. Only rely on this if you have a single CommandBox server running in the current directory.
All the same rules for engine format and version apply.
The version number can be left off toFormat
and fromFormat
when reading or writing to a CFConfig JSON file or a CommandBox server since we already know the version. If you don't specify a Lucee web or Server context, we default to server. Use a format of luceeWeb
to switch.
You can customize what config settings are transferred with the includeList
and excludeList
params. If at least one include pattern is provided, only matching settings will be included. Nested keys such as datasources.myDSN
or mailservers[1]
can be used. You may also use basic wildcards in your pattern. A single *
will match any number of chars inside a key name. A double **
will match any number of nested keys.
Use the append
parameter to merge incoming data with any data already present. For example, if a server already has one datasource defined, and you import a JSON file with 2 more unique datasources, the --append
flag will not remove the pre-existing one.
There are three commands to manage CF mappings.
To receive the data back as JSON, use the --JSON
flag.
Add a new CF mapping or update an existing CF Mapping. Existing mappings will be matched based on the virtual path.
Identify the mapping uniquely by the virtual path.
There are three commands to manage Lucee/Railo caches.
To receive the data back as JSON, use the --JSON
flag.
Add a new cache or update an existing cache. Existing caches will be matched based on the name. You can use a the type
parameter as a shortcut for specifying the full Java class, which may change between versions.
Alternatively, specify the full class name.
If your cache provider expects custom properties, pass them as additional parameters to this command prefixed with the text custom:
. This requires named parameters, of course.
Identify the cache uniquely by the name.
There are three commands to manage Mail Servers.
To receive the data back as JSON, use the --JSON
flag.
Add a new mail server or update an existing mail server. Existing mail servers will be matched based on the host name.
Identify the mail server uniquely by the host name.
Scheduled tasks are supported for both Lucee Server and Adobe ColdFusion. Both engines have some features which are not supported by the other. Check the parameter descriptions in the command help for cfconfig task save
for more info.
All CFConfig commands when run against a Lucee server will default to the fromFormat
or toFormat
to luceeServer
. These commands are a notable exception-- since scheduled tasks can only be imported into a Lucee web context, all commands in the cfconfig task
namespace will default to the luceeWeb
for Lucee servers.
To receive the data back as JSON, use the --JSON
flag.
CFConfig can represent the settings for any server in a generic JSON format. Even though some settings may be specific to Lucee Server or Adobe ColdFusion, the JSON format itself is generic and can be used on any engine. Any settings that don't apply to a given engine will simply be ignored. For example, caches or mail servers past the first one are ignored when importing to Adobe ColdFusion.
You may choose to commit your settings to a file called .cfconfig.json
in the webroot, which will cause them to automatically get loaded in on every server start. This is the easiest way to share configuration with your coworkers. One issue with this may be that you don't want the JSON file in your web root in case it accidentally gets moved to a production server and is directly accessible. Web servers such as Apache will not serve files starting with .
by default, but other web servers will happily share those "hidden" files. You can work around this by placing the JSON file outside the web root and using the cfconfigFile
property in your server.json
to point to it. You can use relative paths like ../build/mySettings.json
.
If you are using Lucee or Railo and wish to have separate config for your server and web contexts, you can use the following file names which will be found by convention if there are no other settings (env vars or server.json
keys specifying JSON file locations).
.cfconfig-server.json
.cfconfig-web.json
If these files exist for an Adobe server, they will still be used.
Another potential issue with the JSON file is that you may have secrets in your config such as passwords that you don't want to commit to your repo or that are simply different on some servers. You can manage this by using CommandBox's "system settings" which will expand any environment variables in your CFConfig JSON file. System settings are in the format ${mySetting}
and would look like so in your JSON file:
That JSON above would automatically replace the adminPassword
setting with the value of an environment variable called LOCAL_DEV_CF_PASS
.
You can take this a step further and provide a default value so the env var is just an override. The format is ${name:default}
.
That JSON above would set the request timeout to 1 minute unless it was overridden by an env var called LOCAL_DEV_TIMEOUT
.
Since scheduled tasks are also managed by CFConfig, any running tasks on the source server will be running on the destination server which might not be desirable. Use these techniques to pause tasks:
In conjunction with the cfconfigFile
in server.json
, set the CFConfigPauseTasks
setting to true with server set CFConfigPauseTasks=true
.
When using CFConfig to import, export, or transfer settings, use the --pauseTasks
flag, i.e., cfconfig import myConfig.json --pauseTasks
.
If you just want to use the core CFConfig services outside the CLI, you can install them like so:
The code in this library has only been tested on Lucee and likely doesn't work on Adobe ColdFusion. If anyone wants to make it compatible, feel free to try but beware of tons of use of the Elvis operator, reliance on sorted JSON structs, and some specific WDDX behavior.
Event Gateway Configurations are currently only supported for Adobe ColdFusion. Please contact us if you'd like to sponsor this feature.
To receive the data back as JSON, use the --JSON
flag.
The variable must start with the text cfconfig_
and will be followed by the name of the setting.
For nested settings inside a struct or array, you can use underscores to represent dots. Note the following will error if there is not already a datasource named myDSN
in the server.
The overrides are applied using the same mechanism that the cfconfig set
command uses, which means you can also pass JSON directly for complex values.
On OS's like Windows which allow for any manner of special characters, you can provide any string which would also be valid for the config set
command. Ex:
When you provide JSON, the append
flag will be set to true when adding the configuration to what's already in CommandBox.
Overridden env vars will not be written to any .cfconfig.json
file and will be lost when box stops. They will also take precedence and override any explicit settings already set.
If you want to specify a setting via an env var that targets a web context, you can use the following conventions:
Every can be overridden by convention by creating environment variables in the shell where you run box
. This is ideal for Docker containers or CI builds where you want to easily set one-off settings and not require an entire JSON file. You can set these as actual environment variables or . Env vars are loaded AFTER any .cfconfig.json
files have been loaded by convention and will override any settings in the JSON. They are not case-sensitive.
Here are the main components in the project
This class represents the configuration of a CF engine. It is agnostic and doesn't contain any particular behavior for a specific engine.
Not all the data it stores applies to every engine though. The BaseConfig.cfc
is not capable of reading or writing the config, it merely holds the data in a generic manner. If you want to read or write to/from a specific engine's format, you'll need to create one of the engine-specific subclasses, all of which extend BaseConfig.cfc
.
JSONConfig.cfc - Engine-agnostic JSON format
Lucee4Server.cfc - Lucee 4.x server context
Lucee4Web.cfc - Lucee 4.x web context
Lucee5Server.cfc - Lucee 5.x server context
Lucee5Web.cfc - Lucee 5.x web context
Railo4Server.cfc - Railo 4.x server context
Railo4Web.cfc - Railo 4.x web context
Adobe9.cfc - Adobe ColdFusion 9
Adobe10.cfc - Adobe ColdFusion 10
Adobe11.cfc - Adobe ColdFusion 11
Adobe2016.cfc - Adobe Coldfusion 2016
Adobe2018.cfc - Adobe Coldfusion 2018
Each of the components above supports these public methods:
setCFHomePath()
- Points to the server home where the config files are to be read or written.
read( CFHomePath )
- Extract the config from the files found in the server home. You can override CFHomePath
here too.
write( CFHomePath )
- Write the config out to the files in the server home whether or not they already exist. You can override CFHomePath
here too.
getMemento()
- Return all configuration in as a raw CFML data structure. Useful for passing config values to another instance.
setMemento()
- Accept configuration as a raw CFML data structure. Useful for accepting another instance's data.
Create an instance of the component that corresponds to the server that you'd like to read or write config settings from, or the BaseConfig
class if you want to deal with the generic JSON-based config.
Create a new JSON configuration file programmatically
Read an existing JSON configuration file
Read an existing Lucee 4 server configuration file
Read an existing JSON config file and load into a Lucee 5 web context
The JSONConfig
will read/write to a JSON file called .CFConfig.json
by default in the home directory you specify. You can alternatively specify a full path to a JSON file to change the name.
The Lucee 4 and Lucee 5 web components expect the CFHomePath
to be the folder containing the lucee-web.xml.cfm
file.
An example would be:
The Lucee 4 and Lucee 5 server components expect the CFHomePath
to be the lucee-server
folder containing the /context/lucee-server.xml
file.
An example would be:
The Adobe components expect the CFHomePath
to be the cfusion
folder that contains the lib/neo-runtime.xml
file.
An example would be:
The code in this library has only been tested on Lucee and likely doesn't work on Adobe ColdFusion. If anyone wants to make it compatible, feel free to try by beware of tons of use of the Elvis operator, reliance on sorted JSON structs, and some specific WDDX behavior.