HTTP bindings are much more robust in Multi-Site mode. In single-site mode, there is basically no such thing as host name bindings. All traffic coming into that CommandBox server is simply routed to the one and only server regardless of its host name or IP address.

As of version 6.0, a CommandBox server can now have

• Any number of HTTP bindings on any IP/port combination

• Any number of SSL bindings on any IP/port combination

• Any number of AJP bindings on any IP/port combination

And furthermore, a binding can be shared for all sites on the server, or could serve traffic to ONLY a single site depending on how you configure it. Think how IIS, Nginx or Apache work. You now have the same level of flexibility in CommandBox!

CommandBox 6 has introduced a new syntax for bindings (and is still backwards compatible with the old JSON syntax too) that allows you to specify hostnames alongside the bindings:

{
  "web":{
    "bindings":{
      "HTTP":{
  
      "listen":"80",
      // or...
      "listen":"*:80",
      // or...
      "listen":"0.0.0.0:80",
      // or...
      "listen":"10.10.0.123:80",
      
      // same as ""
      "host" : "*",
      // or...
      "host":"www.domain.com,www.something.com",
      // or...
      "host": [
        "www.domain.com",
        "www.something.com"
      ]  
  
    }
  }
}

Even though each site can use a different IP/port, a very common setup is to have a single port 80/443 binding at the server level shared by all sites, and then simply specify a hostname for each site. If you only need to specify a host name for a site, but don't need to declare a new binding (because you're inheriting a binding from the global level) then you can use the new hostAlias key at the site level which can be a list or array of hostnames to be layered on top of the global bindings for this site:

{
    "profile":"production",
    "directoryBrowsing":false,
    "hostAlias":"example.com,www.example.com",
    "GZipEnable":false
}

In Multisite mode, each site can have as many bindings as you want, where each binding has:

• An IP address (or all IPs, which is the equivalent to 0.0.0.0)

• A port

• Zero or more hostnames

  • Exact (full) match like www.foo.com

  • Starts-with match like *.foo.com or *bar.com

  • Ends-with match like www.foo.* or www.bar*

  • Regular expression match like ~www\.(bob|tom|bernard)Industries\.(com|net|org)

When a request comes into CommandBox in multi-site mode, the most specific binding will be found, and the traffic served to the matching site. The order of precedence of binding matching is as follows:

• Exact IP and hostname match

• Exact IP and hostname ends with match

• Exact IP and hostname starts with match

• Exact IP and hostname regex match

• Any IP and hostname exact match

• Any IP and hostname ends with match

• Any IP and hostname starts with match

• Any IP and hostname regex match

• Try Exact IP and any hostname

• Any IP and any hostname

• Default site

If you need help debugging how your bindings are being assembled at runtime, you can use this command:

server info --verbose

which will show you all the listeners (ports/IPs) that CommandBox is listening to at the OS level as well as all the bindings for each site that control what listeners will map to them:

  - site1: http://site1.com:80 --> C:\path\to\site1\
      Bindings:
        - 0.0.0.0:80:site1.com

  - site2: http://site2.com:80 --> C:\path\to\site2\
      Bindings:
        - 0.0.0.0:80:site2.com

  - site3: http://site3.com:80 --> C:\path\to\site3\
      Bindings:
        - 0.0.0.0:80:site3.com

  - default: http://127.0.0.1:80 --> C:\path\to\default\
      Bindings:
        - 0.0.0.0:80:*
        - Default Site

  Listeners:
    - HTTP
      - 0.0.0.0:80

If you do not specify any bindings at all, it will still pick a random port to bind to. It will also pick a SEPARATE random port for each site so you can access each site separately.

Each site can have a default open browser URL, but CommandBox will not automatically open a browser in Multi-Site mode. These URLs will be available in a sub menu of the tray icon, or can be used from the server open command like so:

server open siteName=site3

Default site

If no bindings were matched, then CommandBox will look for a default site configuration. Unlike IIS which has a default site created by scratch, or Apache which just takes the first site defined, CommandBox requires you to explicitly define a default site like Nginx. If no default site is defined, CommandBox has a built in "site not found" error page that will be shown. You can avoid or "turn off" this default page by setting a default site.

Configure any of your sites to be the default site by adding a default key set to true inside the site JSON. It doesn't matter whether the site is defined in the server.json in the sites object or in an external site JSON file.

{
  "webroot" : "www/default",
  "default" : true
}

This Github repository has several Multi-Site examples in the folders starting with the words multi-site-. Here is an overview of a few of them.

Basic Multi-Site configured in server.json

Here is a basic server.json configuring several sites. Here we have some defaults configured in the web object for all sites, including a single HTTP binding to all IPs on port 80. There is a custom host alias configured on each site. There is a site called "default" which is set to the default site with default=true in the site object.

{
  "name": "commandbox-test-multi-site-basic",
  "web": {
    "accessLogEnable": "true",
    "aliases": {
      "/js": "javascript"
    },
    "allowedExt": "log",
    "errorPages": {
      "404": "404.cfm"
    },
    "GZIPEnable": "true",
    "gzipPredicate": "regex('^.*\\.txt$')",
    "mimeTypes": {
      "log": "text/plain"
    },
    "rules": [
      "path(/tea)->set-error(418)"
    ],
    "rulesFile": ".rules.txt",
    "welcomeFiles": "custom.cfm,index.cfm",
    "bindings": {
      "HTTP": {
        "listen": "80"
      }
    }
  },
  "sites": {
    "site1": {
      "hostAlias": "site1.com",
      "webroot": "site1"
    },
    "site2": {
      "hostAlias": "site2.com",
      "webroot": "site2",
      "accessLogEnable": "false",
      "aliases": {
        "/js": "site2/javascript"
      },
      "allowedExt": "log2",
      "GZIPEnable": "false",
      "mimeTypes": {
        "log2": "application/xml"
      },
      "rules": [
        "path(/brad)->set-error(123)"
      ],
      "rulesFile": "site2/.rules.txt",
      "welcomeFiles": "index.cfm",
      "directoryBrowsing": true,
      "blockCFAdmin": true
    },
    "site3": {
      "hostAlias": "site3.com",
      "webroot": "site3",
      "aliases": {
        "/js-brad": "site3/javascript"
      },
      "errorPages": {
        "404": "missing.cfm"
      },
      "welcomeFiles": "main.cfm,default.cfm,index.cfm",
      "directoryBrowsing": false,
      "blockCFAdmin": false
    },
    "default": {
      "default": true,
      "webroot": "default",
      "rules": [
        "rewrite(/index.cfm)"
      ]
    }
  }
}

Full example here: https://github.com/Ortus-Solutions/commandbox-tests/tree/master/multi-site-basic

Custom Bindings

This example server contains custom HTTP and SSL bindings for each server. You'll probably never need anything this complex, but we support it all! The HTTP port 81 binding on all IPs, SSL binding on port 444, and AJP binding on port 8010 are shared by all sites. Each site then adds additional bindings specific to the site. Needless to say, there are multiple URLs that lead to each site.

{
    "name":"commandbox-tests-multi-site-bindings",    
    "web":{
        "host":"0.0.0.0",
        "HTTP":{
            "port":"80"
        },
        "SSL":{
            "enable":"true",
            "port":"443",
            "certFile":"../certs/ServerCert-all-SAN.pfx"
        },
        "AJP":{
            "enable":"true",
            "port":"8009",
            "secret":"8009secret"
        },
        "bindings":{
            "HTTP":{
                "listen":"0.0.0.0:8080"
            },
            "SSL":{
                "listen":"0.0.0.0:8443",
                "certFile":"../certs/ServerCert-all-SAN.pfx"
            },
            "AJP":{
                "listen":"0.0.0.0:16009",
                "secret":"16009secret"
            }
        }
    },
    "sites":{
        "site1":{
            "hostAlias":"site1.com",
            "webroot":"site1",
            "bindings":{
                "HTTP":{
                    "listen":"81"
                },
                "SSL":{
                    "listen":"444",
                    "certFile":"../certs/ServerCert-all-SAN.pfx"
                },
                "AJP":{
                    "listen":"8010",
                    "secret":"8010secret"
                }
            }
        },
        "site2":{
            "hostAlias":"site2.com",
            "webroot":"site2",
            "bindings":{
                "http":[
                    {
                        "listen":"0.0.0.0:80"
                    },
                    {
                        "listen":"0.0.0.0:82"
                    }
                ],
                "ssl":{
                    "listen":"0.0.0.0:446",
                    "certFile":"../certs/ServerCert-all-SAN.pfx"
                },
                "AJP":{
                    "listen":"0.0.0.0:8011",
                    "secret":"8011secret"
                }
            }
        },
        "site3":{
            "webroot":"site3"
        }
    },
    "hostAlias":"site3.com"
}

Full example here: https://github.com/Ortus-Solutions/commandbox-tests/tree/master/multi-site-bindings

Web root convention

This example server configures some defaults in the web object and then simply points to the web root of several sites where a .site.json file is waiting to further configure each site:

{
    "name":"commandbox-test-multi-site-json-webroot-convention",
    "web":{
        "mimeTypes":{
            "log":"text/plain"
        },
        "rules":[
            "path(/tea)->set-error(418)"
        ],
        "welcomeFiles":"custom.cfm,index.cfm",
        "bindings":{
            "HTTP":{
                "listen":"80"
            }
        }
    },
    "sites":{
        "site1":{
            "webroot":"site1"
        },
        "site2":{
            "webroot":"site2"
        },
        "site3":{
            "webroot":"site3"
        },
        "default":{
            "webroot":"default"
        }
    }
}

And here are the .site.json files from each of the web roots:

{
    "hostAlias":"site1.com"
}

{
    "hostAlias":"site2.com",
    "accessLogEnable":"false",
    "aliases":{
        "/js":"javascript"
    },
    "allowedExt":"log2",
    "GZIPEnable":"false",
    "mimeTypes":{
        "log2":"application/xml"
    },
    "rules":[
        "path(/brad)->set-error(123)"
    ],
    "rulesFile":"site2/.rules.txt",
    "welcomeFiles":"index.cfm",
    "directoryBrowsing":true,
    "blockCFAdmin":true
}

{
    "hostAlias":"site3.com",
    "aliases":{
        "/js-brad":"javascript"
    },
    "errorPages":{
        "404":"missing.cfm"
    },
    "welcomeFiles":"main.cfm,default.cfm,index.cfm",
    "directoryBrowsing":false,
    "blockCFAdmin":false
}

Full example here: https://github.com/Ortus-Solutions/commandbox-tests/tree/master/multi-site-json-webroot-convention

Per-site siteConfigFile

This example is similar to above, but instead of pointing to the web root of each site, it points to the site config file for each site, which is stored outside of the web roots:

{
    "name":"commandbox-test-multi-site-siteConfigFile",
    "web":{
        "bindings":{
            "HTTP":{
                "listen":"80"
            }
        }
    },
    "sites":{
        "site1":{
            "siteConfigFile":"site1.json"
        },
        "site2":{
            "siteConfigFile":"site2.json"
        },
        "site3":{
            "siteConfigFile":"site3.json"
        },
        "default":{
            "siteConfigFile":"default.json"
        }
    }
}

In this example, the site1.json, site2.json, site3.json, and default.json files all live in the same directory as the server.json and would point to their respective webroots like so:

{
    "hostAlias":"site1.com",
    "webroot":"site1"
}

Full example here: https://github.com/Ortus-Solutions/commandbox-tests/tree/master/multi-site-siteConfigFile

SiteConfigFiles globbing pattern

In this example, we have a single file globbing pattern that points to a directory of JSON files that define the sites:

{
    "name":"commandbox-test-multi-site-siteConfigFiles-globbing",
    "web":{
        "bindings":{
            "HTTP":{
                "listen":"80"
            }
        }
    },
    "siteConfigFiles":"sites-enabled/*.json"
}

In this example, we have a folder called sites-enabled in the same directory as the server.json with one or more JSON files. Here is an example:

{
    "hostAlias":"site1.com",
    "webroot":"../site1"
}

Note the relative paths are always relative to this JSON file.

Full example here: https://github.com/Ortus-Solutions/commandbox-tests/tree/master/multi-site-siteConfigFiles-globbing

The default behavior when you run server start is to start a server that points only to a single web root. There are two methods you can use to host more than one web root at a time in a single CommandBox server:

• - this requires a web server sitting in front of CommandBox which sends special HTTP headers that instruct CommandBox what to use as the web root.

• Multi-Site mode- this is new in CommandBox 6.0 and it allows full configuration of multiple sites (web roots), rewrite, HTTP/SSL bindings, and settings inside of a single server.

In both cases, there is a single JVM process and a single CF Engine at play. So all sites will use the same CF engine and version. If you want to run different versions of CF, you'll need more than one server. You can use a reverse proxy in your server rules to still access all your sites via a single "front end" server instance.

The CommandBox built-in web server is now fully fledged with out-of-the-box support for multiple bindings, host header matching, multiple SSL certs/SNI, and full control over rewrites gzip compression, virtual directories (aliases) and secure profiles on a per-site basis. CommandBox is now truly the only tool you need to deploy your code! There's no need to have Apache, IIS, or Nginx in the mix any longer.

There is a repo on Github that contains working examples of all the features of Multi-Site. Feel free to skip straight there to learn by example.

Tuckey Rewrites

Please note that the using Tuckey will NOT work by default in Multi-Site mode. There are two main reasons for this limitation:

• Tuckey is tied to the servlet and static files are now no longer served by the Default Servlet, but are returned to the browser without even touching the servlet.

• There is only one servlet servicing all sites, so you can't have different rewrites per site.

Not ready to leave Tuckey? You can force the new Undertow web server to not serve static files by setting servletPassPredicate=true, which will send ALL files to the servlet:

Read more about the .

However, the best approach is to simply switch over to using . They do everything Tuckey does, AND each site can get its own separate set of server rules for maximum configurability.

Also note, when you set this flag:

as of CommandBox 6, a Tuckey XML rewrite file will no longer be employed. Instead Server Rules will be added that perform the same rewrites as the old Tuckey functionality. Tuckey will now ONLY be used if you specify a custom rewrite file.

There's no flag or setting for enabling multiple sites in a single server. All you have to do is

• define a sites object in server.json

• or a siteConfigFiles setting in server.json

inside your server.json and if one or more sites are found, CommandBox will automatically switch over to "Multi-Site" mode. It's easy to tell if a server has more than one site. When you start it, the console output will have a dedicated section in the output for each site. There is also additional information in the server info command about each site.

❯ start --dryRun
 √ | Starting Server
   | √ | Configuring site [site1]
   |   | √ | Setting site [site1] Profile to [production]
   | √ | Configuring site [site2]
   |   | √ | Setting site [site2] Profile to [production]
   | √ | Configuring site [site3]
   |   | √ | Setting site [site3] Profile to [production]

Let's explore the two methods of defining more sites.

Define a "sites" object in server.json

The sites object will have a key for each site you want to define where the name of the key is the name of each site and the value is another object containing the configuration of that site. Think of all of the setting which can be set in the web object of server.json. Each site object in the sites object can have all the same settings as the top-level web object so it will be very familiar.

{
    "name":"My server",
    "web":{
        // These settings apply to all sites
        "accessLogEnable":"true",
        "bindings":{
            "HTTP":{
                "listen":"80"
            }
        }
    },
    "sites":{
        "site1":{
            "hostAlias":"site1.com",
            "webroot":"/path/to/site1"
        },
        "site2":{
            "hostAlias":"site2.com",
            "webroot":"/path/to/site2",
            // Overrides the default above coming from "web"
            "accessLogEnable":"false",
        }
    }
}

The simple example server.json above, some defaults that apply to all sites are defined in the top-level web object. Then we have two sites, site1 and site2 defined with their own settings. Remember, each site object is just a copy of the web object above, so all the same settings are valid. You can use the server set command to configure these and rely on the tab completion to help prompt you with all valid options.

The ONLY required settings for each site are

• webroot

• or siteConfigFile which points to a JSON file on disk where a web root must be defined

{
    "sites":{
        "client-1":{
            "siteConfigFile":"/var/www/client1-site.json"
        },
        "client-2":{
            "siteConfigFile":"/var/www/client2-site.json”
        }
    }
}

If you want to access each site individually, you'll either want to specify a separate HTTP/SSL/AJP binding OR a custom hostname for each site. Otherwise, you'll have no way to access them!

You can also place a .site.json file inside of the web root, which will be found by convention and its contents will be added to the site object for that site. This is akin to configuring your sites in Apache, but having an .htaccess file in each web root to override settings.

System setting expansions will be processed in any .site.json files, and if a .env file exists in the web root as well, thoses env vars will be loaded, but JUST for that .site.json file's expansions.

Define a siteConfigFiles setting in server.json

If you have a lot of sites, or a lot of settings, the first option can become unwieldly since the server.json will have a lot of stuff in it. That is why we also allow you to specify a siteConfigFiles setting which contains a list or array of file globbing patterns or directories to look for JSON files in. Once all the JSON files have been found, they will be used to define sites. each JSON file will contain JUST the contents of the object you would have put in the sites object of server.json which has all the same options as a web object in server.json.

Valid examples could be:

{
    "name":"My server",
    "web":{
        // These settings apply to all sites
        "accessLogEnable":"true",
        "bindings":{
            "HTTP":{
                "listen":"80"
            }
        }
    },
    "siteConfigFiles" : "C:/absolute/path/to/configs/"
    // or...    
    "siteConfigFiles" : "../relative/path/to/configs/"
    // or...    
    "siteConfigFiles" : "../marketingSites/*-active.json,../internalSites/**/*-active.json"
    // or...    
    "siteConfigFiles" : [
        "../marketingSites/*-active.json",
        "../internalSites/**/*-active.json"
    ]
    // or...    
    "siteConfigFiles" : [
        "../sites/site1.json",
        "../sites/site2.json",
        "../sites/site3.json"
    ]
}

System setting expansions will be processed in any of the site JSON files located via your file globbing patterns. If the server.json has a sites object AND a siteConfigFiles setting, all sites will be combined together. Feel free to choose the approach that fits your needs!

In a traditional server setup, you are used to two separate pieces of software

• A web server like NGinx, Apache, or IIS which serves static files, performs URL rewrites, and proxies some requests off to a servlet

• A Servlet container like Tomcat or CommandBox receiving the proxied requests on another port (HTTP or AJP) and processing CF code

In CommandBox, now we have the ability to combine both of those bullets together into a single piece of software. No reverse proxy is needed, nor is a second port to proxy to.

In all cases with the legacy setup, there is always a check of some kind that decides which requests will get sent to the servlet. This is usually checking for URLs ending in .cfm or .cfc. Common implementations of this are:

• Adobe's CF connector

• The mod_cfml module for Apache

• BonCode for IIS

• A custom proxy directive in your web server.

As of CommandBox 6, we have the same setting and it can be set as web.servletPassPredicate which is simply an Undertow Predicate. By default, CommandBox uses the following predicate for the servletPassPredicate:

regex( '^/(.+?\\.cf[cm])(/.*)?$' )

So the URI /index.cfm will get sent to the servlet, but /test.txt would just get sent by the static file resource handler. You can customize this if necessary with any valid Undertow predicate. It can even be different on a per-site basis by setting it inside the sites object or .site.json file for a given site.

# Send ALL traffic to the servlet (the servlet's default handler will serve static files)
server set web.servletPassPredicate=true

# Only serve CF files out of the cgi folder
server set web.servletPassPredicate="regex( '^/cgi/(.+?\\.cf[cm])(/.*)?$' )"

# process CFM files or anything in the /REST/ directory
server set web.servletPassPredicate="regex( '^/(.+?\\.cf[cm])(/.*)?$' ) or path-prefix-nocase( /REST/ )"

Note, be careful as your servlet pass setting may send .cfm files to the static file handler. CommandBox has a failsafe in place to prevent the source code from being returned, but you should still use caution when configuring this.

As soon as CommandBox flips over to Multi-Site mode, the settings in the web object will become defaults that apply to all sites. This allows you to group global settings into the top-level web object and then override what you need for each site. Here is the full order of precedence for what settings will be applied:

• settings in a .site.json file inside a web root of a site

• settings in an external site JSON file pointed to by the siteConfigFiles setting in server.json

• site-specific object in the sites object of server.json

• settings in the web object of server.json

• server.default settings in CommandBox's global config settings

Settings global to a server

Since all sites for a given server do run inside the same JVM, there are some settings which cannot be customized on a per-site basis. They are as follows:

• JRE/JDK the server runs on

• JVM args, heap size

• CF Engine/version

• Console log

• Tuckey Rewrites (part of servlet)

• Environment Variables

• Tray icon (there is a single tray icon for the entire server)

Per-site settings

Everything normally set in the web block of your server.json can be configured separately for each site. These settings include:

• GZIp enabled and GZip predicate

• Access log

• Use proxy forwarded IP

• CommandBox Server Rules (Undertow Predicate Language)

  • SSL settings (HSTS, SSL Redirect)

  • Block CF Admin

  • Block flash remoting

  • Block sensitive paths

• Security

  • Basic auth

  • Client cert auth

  • Security predicate

• Custom error pages (404, 500, etc)

• Mime types

• Welcome files

• Allowed file extensions

• Directory browsing

• Aliases/Virtual dirs

• File cache settings

• Case sensitive paths

• Web root

• Server Profile (even though this is not inside the web object in your server.json, it can still be set in a sites block to override for that site.)

And remember, all of the settings in the section above can be defaulted for all sites in the web block at the top of your server.json and then overridden in the sites.siteName block or in a .site.json file.

Debugging settings

There is much-improved console output now coming from Runwar when the server starts up. Add --verbose or --debug to your server start command and you'll see site debug output at the top of the server start in the interactive job output:

   |   |--------------------------------------------------------------
   | √ | Configuring site [site1]
   |   |---------------------------------------
   |   | Site name - site1
   |   | Webroot - C:\path\to\site1\
   |   | Site config file - C:\path\to\server.json
   |   |---------------------------------------
   |   | √ | Setting site [site1] Profile to [development]
   |   |   |------------------------------------------------------------
   |   |   | Profile set from server bound to localhost
   |   |   | Block CF Admin disabled
   |   |   | Block Sensitive Paths enabled
   |   |   | Block Flash Remoting enabled
   |   |   | Allowed Extensions: [log]
   |   |   | Directory Browsing enabled
   |   |   | File Caching disabled
   |   |   |------------------------------------------------------------
   | √ | Configuring site [site2]
   |   |---------------------------------------
   |   | Site name - site2
   |   | Webroot - C:\path\to\site2\
   |   | Site config file - C:\path\to\server.json
   |   |---------------------------------------
   |   | √ | Setting site [site2] Profile to [development]
   |   |   |------------------------------------------------------------
   |   |   | Profile set from server bound to localhost
   |   |   | Block CF Admin enabled
   |   |   | Block Sensitive Paths enabled
   |   |   | Block Flash Remoting enabled
   |   |   | Allowed Extensions: [log2]
   |   |   | Directory Browsing enabled
   |   |   | File Caching disabled
   |   |   |------------------------------------------------------------
   | √ | Configuring site [site3]
   |   |---------------------------------------
   |   | Site name - site3
   |   | Webroot - C:\path\to\site3\
   |   | Site config file - C:\path\to\server.json
   |   |---------------------------------------
   |   | √ | Setting site [site3] Profile to [development]
   |   |   |------------------------------------------------------------
   |   |   | Profile set from server bound to localhost
   |   |   | Block CF Admin disabled
   |   |   | Block Sensitive Paths enabled
   |   |   | Block Flash Remoting enabled
   |   |   | Allowed Extensions: [log]
   |   |   | Directory Browsing disabled
   |   |   | File Caching disabled
   |   |   |------------------------------------------------------------
   | √ | Configuring site [default]
   |   |-----------------------------------------
   |   | Site name - default
   |   | Webroot - C:\path\to\default\
   |   | Site config file - C:\path\to\server.json
   |   |-----------------------------------------
   |   | √ | Setting site [default] Profile to [development]
   |   |   |--------------------------------------------------------------
   |   |   | Profile set from server bound to localhost
   |   |   | Block CF Admin disabled
   |   |   | Block Sensitive Paths enabled
   |   |   | Block Flash Remoting enabled
   |   |   | Allowed Extensions: [log]
   |   |   | Directory Browsing enabled
   |   |   | File Caching disabled
   |   |   |--------------------------------------------------------------

Furthermore, once the actual server process gets underway, with the --trace flag you'll see additional console output like so:

[INFO ] Runwar: ******************************************************************************
[INFO ] Runwar: Starting Runwar
[INFO ] Runwar:   - Runwar Version: 5.0.0-SNAPSHOT
[INFO ] Runwar:   - Java Version: 11.0.22+7 (Eclipse Adoptium)
[INFO ] Runwar:   - Java Home: C:\path\to\jre
[INFO ] Runwar: ******************************************************************************
[INFO ] Runwar: Listeners:
[INFO ] Runwar:   - Binding HTTP on 0.0.0.0:80
[DEBUG] Runwar:      Setting HTTP/2 enabled: true
[INFO ] Runwar: ******************************************************************************
[INFO ] Runwar: Configuring Servlet
[DEBUG] Runwar:   File cache is disabled
[DEBUG] Runwar:   Ignoring web.xml welcome file, so adding server options welcome files to deployment manager.
[INFO ] Runwar:   Found WEB-INF: 'C:\path\to\WEB-INF'
[DEBUG] Runwar:   Parsing 'C:\path\to\WEB-INF\web.xml'
[TRACE] Runwar:     Total No. of context-params: 0
[TRACE] Runwar:     Total No. of listeners: 0
[TRACE] Runwar:     Total No. of servlets: 2
[TRACE] Runwar:       servlet-name: CFMLServlet, servlet-class: lucee.loader.servlet.CFMLServlet
[TRACE] Runwar:       servlet-name: RESTServlet, servlet-class: lucee.loader.servlet.RestServlet
[TRACE] Runwar:       Mapping servlet-name: CFMLServlet, url-pattern: *.cfc
[TRACE] Runwar:       Mapping servlet-name: CFMLServlet, url-pattern: *.cfm
[TRACE] Runwar:       Mapping servlet-name: CFMLServlet, url-pattern: *.cfml
[TRACE] Runwar:     Total No. of welcome files: 4
[TRACE] Runwar:       welcome-file: index.cfm
[TRACE] Runwar:       welcome-file: index.lucee
[TRACE] Runwar:       welcome-file: index.html
[TRACE] Runwar:       welcome-file: index.htm
[INFO ] Runwar: ******************************************************************************
[INFO ] Runwar: Creating deployment [default]
[DEBUG] Runwar:   Initialized MappedResourceManager
[INFO ] Runwar:     Web Root: C:\path\to\default
[DEBUG] Runwar:     Aliases: {/js=C:\path\to\javascript}
[DEBUG] Runwar:   Adding Mime types
[TRACE] Runwar:   - log = 'text/plain'
[DEBUG] Runwar:   New servlet context created for [default]
[DEBUG] Runwar: ******************************************************************************
[INFO ] Runwar: Creating deployment [site3]
[DEBUG] Runwar:   Initialized MappedResourceManager
[INFO ] Runwar:     Web Root: C:\path\to\site3
[DEBUG] Runwar:     Aliases: {/js=C:\path\to\javascript, /js-brad=C:\path\to\site3\javascript}
[DEBUG] Runwar:   Adding Mime types
[TRACE] Runwar:   - log = 'text/plain'
[DEBUG] Runwar:   New servlet context created for [site3]
[DEBUG] Runwar: ******************************************************************************
[INFO ] Runwar: Creating deployment [site1]
[DEBUG] Runwar:   Initialized MappedResourceManager
[INFO ] Runwar:     Web Root: C:\path\to\site1
[DEBUG] Runwar:     Aliases: {/js=C:\path\to\javascript}
[DEBUG] Runwar:   Adding Mime types
[TRACE] Runwar:   - log = 'text/plain'
[DEBUG] Runwar:   New servlet context created for [site1]
[DEBUG] Runwar: ******************************************************************************
[INFO ] Runwar: Creating deployment [site2]
[DEBUG] Runwar:   Initialized MappedResourceManager
[INFO ] Runwar:     Web Root: C:\path\to\site2
[DEBUG] Runwar:     Aliases: {/js=C:\path\to\site2\javascript}
[DEBUG] Runwar:   Adding Mime types
[TRACE] Runwar:   - log2 = 'application/xml'
[TRACE] Runwar:   - log = 'text/plain'

This is what a typical ColdFusion deployment looks like. A separate web server sites in front, bound to ports 80 and 443 and proxies back to a Tomcat-based servlet:

CommandBox's Servlet configuration

For a CommandBox server, we replace the green box above with JBoss Undertow instead of Tomcat and we configure it on the fly with CommandBox. Here's a look under the covers at what the internal pieces of CommandBox look like for a single site server.

We have a set of HTTP/SSL/AJP listeners that feed through a single handler chain of configuration that funnel requests to the servlet deployment where the CF engine's libs are loaded. The default servlet serves static files via the singular resource manager configured to look in the web root.

CommandBox Multi-Site with Lucee

Here is what a Multi-Site server looks like under the covers for Lucee Server (which works differently than Adobe). This is mostly the same regardless of whether you're using ModCFML or the new Multi-Site features.

Here the listeners funnel to a handful of different initial handler chains, which represent the different configuration between sites. The Lucee jars are loaded once and the Lucee Servlet Context exists once. Each site has a separate servlet deployment where a separate Lucee Web Context lives, along with their own CFML Servlet, default servlet, and resource manager configured for their separate web root.

In Multi-Site mode, static files are NOT served by the default servlet, but instead by an Undertow resource handler in the initial handler chain. The web.servletPassPredicate controls what requests even reach the servlet. Static files are served without ever touching the servlet.

CommandBox Multi-Site with Adobe CF

Here is what a Multi-Site server looks like under the covers for Adobe ColdFusion (which works differently than Lucee). This is the mostly the same regardless of whether you're using ModCFML or the new Multi-site features.

Like the Lucee example above, the listeners pass requests off to one of several initial handler chains, which represent different per-site configurations. However, we only have a single servlet deployment in this case and a single default servlet. The resource manager delegates out to sub-resource managers based on the site being accessed to switch out the web root as necessary.

In Multi-Site mode, static files are NOT served by the default servlet, but instead by an Undertow resource handler in the initial handler chain. The web.servletPassPredicate controls what requests even reach the servlet. Static files are served without ever touching the servlet.