Activate and deactivate blades
Platform blades can be active or inactive. Here’s how to change the active/inactive state of a blade, and a note about managing the states of mutually exclusive blades.
In the following steps you’ll be using the For a list of |
Activating a blade
To activate a blade, use the Deployment Framework’s activate command.
For example, to activate Liberator’s HTTPS blade, follow the steps below on each server in your deployment infrastructure:
-
Enter the command below to shutdown all running core components and integration adapters:
./dfw stop
-
Enter the command below to activate Liberator’s HTTPS blade:
./dfw activate HTTPS
To avoid misspelling the name of the blade or typing the name of an already activated blade, enable the DFW’s command-line completion. See Setting up dfw command-line completion. -
Enter the command below to start core components and integration adapters:
./dfw start
Deactivating a blade
To deactivate a blade, use the Deployment Framework’s deactivate command.
For example, to deactivate Liberator’s HTTP blade, follow the steps below on each server in your deployment infrastructure:
-
Enter the command below to shutdown all running core components and integration adapters:
./dfw stop
-
Enter the command below to deactivate Liberator’s HTTP blade:
./dfw deactivate HTTP
-
Enter the command below to start core components and integration adapters:
./dfw start
Managing mutually exclusive blades
Some blades are mutually exclusive because they provide different versions of the same feature, so you should only make one of them active at a time.
For example, Liberator has two website blades: LiberatorWebsite and MinimalLiberatorWebsite. Only one of these blades can be active at a time.
If you do activate two mutually exclusive built-in blades, the activate
command reports the clash, and you won’t be able to start the Framework.
You can can manage the compatibility of Platform blades that you write by adding entries to the blade control file. |
See also: