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: