The Deployment Framework command utility (dfw)

./dfw activate <bladename1> <bladename2> …​

Activates a blade or blades.

You won’t see the effects of activating the blade(s) until you restart the system (see ./dfw start).

./dfw clean [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Removes all log files that have been produced by the deployed core components (Liberator and/or Transformer) and active Adapter blades.

./dfw cleanstart [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Stops all the deployed components, removes log files (as for ./dfw clean), and starts the system again.

./dfw cmc

Starts the Caplin Management Console (CMC) if it’s installed and there’s a CMC configuration file available. (Use the command ./dfw mon to create the configuration file.)

If you forget to do this, the cmc command responds with these error messages:

This happens because the default session name when you use Remote Desktop is something like RDP-Tcp#0 whereas the CMC startup command expects it to be Console

./dfw deactivate [<bladename1> <bladename2> …​]

Deactivates a blade or blades.

You won’t see the effects of deactivating the blade(s) until you restart the system (see ./dfw start).

./dfw delete [<bladename1> <bladename2> …​]

Deactivates and deletes a blade or blades.

./dfw deploy [-f] [<kitname1> <kitname2> …​]

Use this command to deploy core components and blade kits. The core components and all blades supplied by Caplin Systems are delivered in kit form. This command unpacks any kits that are in the Framework’s kits directory and any kits provided on the command line, and activates each unpacked blade. When a kit has been deployed from the kits directory, the command moves the kit file to <Framework-root>/kits/archive/ directory.

If any kit location provided on the command line has spaces in the path, enclose the whole thing in double quotes ("). You can use wildcards in the pathnames.

Use the -f parameter to remove the Framework files relating to older kit versions without the command prompting you. However, if you do remove the files for an older kit version (either using -f or in response to a prompt), you can’t subsequently revert to that kit using the rollback command - you’ll have to redeploy the kit instead.

Also see the redeploy and rollback commands.

./dfw dump [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Stops the system (all the deployed components) and dumps configuration information for each deployed core component (Liberator and/or Transformer) and Adapter blade. The dumped information is in files in directories under global_config/dump. Each dumped file contains every original configuration line with its filename and line number, followed by the same lines with any configuration macros translated to their actual values. All the configuration within any included files is listed in the same way.

./dfw hosts

./dfw hosts [<AdapterBladename1>|<AdapterBladename2>|Liberator|Transformer] <primary-host> [<secondary-host>]

./dfw hosts [all] <primary host> [<secondary host>]

Sets the hosts that you want Liberator and/or Transformer and/or particular Adapter blades to run on.

Example:

This sets all your Adapter blades, Liberator and (if deployed) Transformer to start on your machine.

./dfw info

Displays information about the core components (Transformer and/or Liberator) and the currently active blades. This includes:

./dfw java <JVM-location-and-name>

Sets up the location and name of the JVM (Java Virtual Machine) for use by Liberator and Transformer and any C-based Adapter blades. It defines this as a configuration macro called JVM_LOCATION (see Configuration macros and items).

The <JVM-location-and-name> parameter must be a Linux style pathname with forward slash (/) separators, even if it’s a Windows path. Don’t use Windows-style backslash (\) separators - the command won’t find the path.

Example (for Windows):

If the path name in <JVM-location-and-name> contains spaces, enclose the whole thing in double quotes ("), or escape the spaces.

./dfw java32 <JVM32-location-and-name>

Sets up the location and name of the 32 bitJVM (Java Virtual Machine) in Linux environments, for use by 32 bit C-Based Adapter blades. It defines this as a configuration macro called JVM_LOCATION32 (see Configuration macros and items).

Example:

If the path name in <JVM32-location-and-name> contains spaces, enclose the whole thing in double quotes ("), or escape the spaces.

./dfw killAll

Kills all processes that were started from the dfw directory. Run this command if ./dfw stop didn’t stop all of the processes that were started by the ./dfw start or ./dfw cleanstart command.

./dfw logs [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Copies all log files produced by the Framework components to directories under <Framework-root>/global_config/logs/, removing any existing logs at the target location.

./dfw mon

Creates a configuration file for the Caplin Management Console (CMC). The file includes configuration relating to all the JMX-enabled DataSource peers that are currently deployed.

./dfw redeploy [-f] [<kitname1> <kitname2> …​]

This convenience command re-deploys one or more core components and/or blade kits that were previously deployed (see the deploy command). redploy obtains the kit(s) from the Deployment Framework’s kits archive directory (<Framework-root>/kits/archive/); it saves you from having to look in the archive, find the full file names of the required kits and then supply these names to the deploy command.

The most convenient way to use this command is with tab completion to select each archived kit that you want to redeploy.

To revert to using another previously deployed kit without redeploying it, use the rollback command.

Use the -f parameter to remove the Framework files relating to older kit versions without the command prompting you. However, if you do remove the files for an older kit version (either using -f or in response to a prompt), you can’t subsequently revert to that kit using the rollback command - you’ll have to redeploy the kit instead.

redeploy is only available in Deployment Framework release 6.2.1 and later.

./dfw rollback [<kitname1> <kitname2> …​]

Rolls back one or more core components and/or blades to previously unpacked (deployed) kits. This command is useful when you’ve deployed a Platform component or blade that turns out to be faulty and you want to revert to a previous good version without having to redeploy it.

For example, assume that you originally deployed Liberator 6.2.5 and Transformer 6.2.4 and you then upgraded both these components by deploying the newer versions Liberator 6.2.6 and Transformer 6.2.5, keeping in place the files for the older versions. If you subsequently decide that you need to roll back to using the older versions, you would run the command:

Note that unlike the deploy and redeploy commands, you don’t supply a file extension in the kit name parameter (Liberator-6.2.5-<build-no> not Liberator-6.2.5-<build-no>.zip)

The rollback command doesn’t unpack the selected kits again; it just changes the links that point to the currently deployed kits. In the above example, the link called Latest in <Framework-root>/kits/Liberator/ is changed, and so is the Latest link in <Framework-root>/kits/Transformer/

You can use the command to roll forwards as well as back. Following on from the previous example, to roll forward to the latest Liberator and Transformer that was previously deployed, you would run the command:

The most convenient way to use this command is with tab completion, which will allow you to easily select the unpacked kits you want to restore.

If you want to revert to a kit for which you had previously removed the Framework files (for example, by running deploy or redeploy with the -f option), the kit won’t be available to the rollback command; you’ll have to redeploy it instead.

If there’s only one version of a particular kit deployed, the command presents this kit as available to rollback to, but the rollback is a "null" operation.

rollback is only available in Deployment Framework release 6.2.1 and later.

./dfw start [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Stops the core components (Transformer and/or Liberator) and Adapter blades and starts them up again.

./dfw status

Reports the status of the core components (Transformer and/or Liberator) and Adapter blades, showing the process id of each process running under the Framework.

./dfw stop [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Stops the core components (Transformer and/or Liberator) and Adapter blades.

./dfw validate

Checks that the currently active blades are consistent with the list of active blades maintained by the Framework. This command also reports on any blades that have been copied directly into the <Framework-root>/active_blades/ directory instead of being activated using the command ./dfw activate.

./dfw versions

Displays the versions of every deployed kit (including the Deployment Framework itself), and also which blades are active and inactive.

If multiple versions of the same kit have been deployed only the version of the most recent deployment is reported.

Note that the kit name for a blade includes the blade name but is not not necessarily identical to it. For example, the Caplin Permissioning Service blade is called PermissioningService but the associated kit is called CPB_PermissioningService-<version>.zip.

./dfw veryclean [Liberator] [Transformer] [<AdapterBladename1> <AdapterBladename2> …​] [servers]

Removes all log files that have been produced by the deployed components and active Adapter blades. When you explicitly or implicitly include Liberator in the command parameters, the command also removes the database files containing information about the Liberator users' licence usage. When you explicitly or implicitly include Transformer in the command parameters, the command also cleans up Transformer’s memory file.

If you don’t want the licence database files to be removed, or Transformer’s memory file to be cleaned up, use the command ./dfw clean instead: