Below you can see a diagram of what happens when modules get activated right after registration:

The beauty of ColdBox Modules is that you have an internal module service that you can tap in order to dynamically interact with the ColdBox Modules. This service is available by talking to the main ColdBox controller and calling its getModuleService() method or via dependency injection.

However, before we start reviewing the module service methods let's review how modules get loaded in a ColdBox application. Below is a simple bullet point of what happens in your application when it starts up:

1. ColdBox main application and configuration loads

2. ColdBox Cache, Logging and WireBox are created

3. Module Service calls on registerAllModules() to read all the modules in the modules locations (with include/excludes) and start registering their configurations one by one. If the module had parent settings, interception points, datasoures or webservices, these are registered here.

4. All main application interceptors are loaded and configured

5. ColdBox is marked as initialized

6. Module service calls on activateAllModules() so it begins activating only the registered modules one by one. This registers the module's SES URL Mappings, model objects, etc

7. afterConfigurationLoad interceptors are fired

You can also use the same module service methods to load ANY module in ANY ColdFusion reachable location. This is huge for applications that need granular control of loading and unloading of modules. You will do this with our magic method:

registerAndActivateModule(moduleName,[instantiationpath])

This time, you will pass an instantiation path to the method. This is the dot notation path up to the folder that contains the module. So let's say your module to load is located here:

/shared
  /modules
    /Calendar
      +ModuleConfig.cfc

You will then issue the following:

controller.getModuleService().registerAndActivateModule('Calendar','shared.modules')

Caution The instantiation path does NOT include the name of the module on disk as the name is the module name you already pass into the method.

If you want to load a new module in your application that you have just installed you need to do a series of steps.

1. Drop the module in any of the module locations defined or an a-la-carte location

2. Call registerAndActivateModule(moduleName,[instantiationPath]) to register and activate the module

controller.getModuleService().registerAndActivateModule('TaskManager');

Here are the most common methods you can use to manage modules:

• reloadAll() : Reload all modules in the application. This clears out all module settings, re-registers from disk, re-configures them and activates them

• reload(module) : Target a module reload by name

• unloadAll() : Unload all modules

• unload(module) : Target a module unload by name

• registerAllModules() : Registers all module configurations

• registerModule(moduleName,[instantiationPath]) : Target a module configuration registration

• activateAllModules() : Activate all registered modules

• activateModule(moduleName) : Target activate a module that has been registered already

• getLoadedModules() : Get an array of loaded module names

• rebuildModuleRegistry() : Rescan all the module locations for newly installed modules and rebuild the registry so these modules can be registered and activated.

• registerAndActivateModule(moduleName,[instantiationPath]) : Register and Activate a new module

With these methods you can get creative and target the reloading, unloading or loading of specific modules. These methods really open the opportunity to build an abstraction API where you can install modules in your application on the fly and then register and activate them. You can also do the inverse and deactivate modules in a running application.

The module service also announces several events or interception points as you saw from the life cycle diagrams. Below are the events announced:

preModuleLoad

Fired before a module is about to be activated.

Data:

• moduleLocation - The location of the loaded module

• moduleName - The name of the module

postModuleLoad

Fired after a module has been successfully activated

Data:

• moduleLocation - The location of the loaded module

• moduleName - The name of the module

• moduleConfig - The module configuration structure

preModuleUnload

Fired before a module is about to be unloaded

Data:

• moduleName - The name of the module

postModuleUnload

Fired after a module has been unloaded

Data:

• moduleName - The name of the module

Below you can see a diagram of what happens when modules get deactivated and unloaded

Below you can see a diagram of what happens when modules get registered: