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.

Tip: In the following steps you'll be using the dfw command of the Deployment Framework. Before entering any dfw command as ./dfw <command-name>, make sure your current (working) directory is set to the Deployment Framework's topmost directory.

For a list of dfw commands, click here.

Warning: before running any Deployment Framework (DFW) command that configures the framework, use the DFW stop command to stop all running core components and adapters. DFW commands that configure the framework include: deploy, activate, deactivate, redeploy, rollback, delete, erase, hosts, and java.

Contents:

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:

  1. Enter the command below to shutdown all running core components and integration adapters:

    ./dfw stop
  2. Enter the command below to activate Liberator's HTTPS blade:

    ./dfw activate HTTPS
    Tip: 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.
  3. 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:

  1. Enter the command below to shutdown all running core components and integration adapters:

    ./dfw stop
  2. Enter the command below to deactivate Liberator's HTTP blade:

    ./dfw deactivate HTTP
  3. 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, these pairs of Config blades that are built into the Deployment Framework are mutually exclusive:

  • OpenPermissioning and Permissioning
  • LiberatorWebsite and MinimalLiberatorWebsite

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.

Tip: You can can manage the compatibility of Platform blades that you write by adding entries to the blade control file.

See also: