Multiple Applications

Fusebox 4.1 only allowed one Fusebox application per ColdFusion application because it used application.fusebox as the single location for the framework's cached data. Fusebox 5 allows you to specify the key used inside application scope to store that data. By default, the key is fusebox, for backward compatibility. You can change the key by setting FUSEBOX_APPLICATION_KEY in your index.cfm file, prior to including /fusebox5/fusebox5.cfm.

For example:

/app1/index.cfm

<cfapplication name="mysite">
<cfinclude template="/fusebox5/fusebox5.cfm">

/app2/index.cfm

<cfapplication name="mysite">
<cfset FUSEBOX_APPLICATION_KEY = "app2">
<cfinclude template="/fusebox5/fusebox5.cfm">

/app3/index.cfm

<cfapplication name="mysite">
<cfset FUSEBOX_APPLICATION_KEY = "app3">
<cfinclude template="/fusebox5/fusebox5.cfm">

The first application uses application.fusebox, just like Fusebox 4.1. The second and third applications take advantage of the new FUSEBOX_APPLICATION_KEY parameter to cache the Fusebox data in application.app1 and application.app3 respectively. All three Fusebox applications co-exist in the same ColdFusion application mysite, able to share application and session data.

Inside your application code, including inside a plugin, you can use either of the following techniques to access the Fusebox data structure in application scope:

  • application[FUSEBOX_APPLICATION_KEY] - FUSEBOX_APPLICATION_KEY defaults to fusebox so this is like application.fusebox
  • myFusebox.getApplication() - this is the preferred way to refer to the Fusebox application object

Application initialization

Fusebox 4.1 provides two ways to execute code at the beginning of every request:

  • <globalfuseactions> / <preprocess> in fusebox.xml
  • fusebox.init.cfm

Unfortunately, Fusebox 4.1 does not provide any way to execute code when the application starts up so what you have to do is put conditional logic in the <preprocess> fuseaction and/or the fusebox.init.cfm and you have to deal with locking in order to remain thread safe. ColdFusion MX 7 introduced Application.cfc which has an onApplicationStart() method that lets you specify per-application initialization code without conditionals and without locking. Fusebox 5 introduces a way to specify per-application initialization code without conditionals and without locking, that works on every CFML engine:

  • <globalfuseactions> / <appinit> in fusebox.xml
  • fusebox.appinit.cfm

The fuseaction specified in <appinit> is executed only on the first request after the framework is loaded and the framework automatically locks execution to ensure thread safety. The same is true of fusebox.appinit.cfm which is included immediately after the framework is loaded, before the request is compiled and processed, again inside a lock to ensure thread safety. Be aware, however, that the named locks used for <appinit> and fusebox.appinit.cfm are different. fusebox.appinit.cfm executes as part of the framework load process, even before fusebox.init.cfm is executed, and is thread safe in that context. <appinit> executes conditionally as part of each request and is thread safe in that context. Care should be exercised when using both fusebox.appinit.cfm and <appinit> to perform initialization within the same application - it is recommended that you use one form or the other, but not both.

Note that the fuseaction specified in <appinit> executes outside the normal fuseaction lifecycle: no plugins are executed as part of the application initialization. The <appinit> fuseaction must therefore not depend on any plugin behavior. However, this allows any and all of the plugin points to safely depend on code that is executed as part of application startup.