Lifecycle Handler

From wiki.gpii
Jump to: navigation, search

Description

Lifecycle handlers are functions used as part of the starting and stopping of solutions, as coodinated by the Lifecycle Manager. Typically, a lifecycle handler carries out a single, specific task, such as:

  • invoking the appropriate Settings Handler to get, set or restore the settings;
  • executing system and other external calls;
  • launching or killing a solution.

Several lifecycle handlers may need to be combined to start or stop a given solution.


Lifecycle handlers are registered with the Lifecycle Manager as part of a solution declaration registered with the Solution Registry.

Individual solutions may need to define solution-specific lifecycle handlers, but the GPII/Cloud4All architecture has a set of built-in lifecycle handlers available:

Regular Lifecycle Handlers:

  • System call handler: execs system commands.
  • GSettings handler: can set gsettings values used in Gnome (linux) and other

Special Lifecycle Handlers:

  • "setSettings": special lifecycle handler that tells the LifecycleManager to use the settings handlers defined in the settingsHandlers block to set the settings.
  • "restoreSettings": special lifecycle handler that tells the LifecycleManager to use the settings handlers defined in the settingsHandlers block to reset the settings.

These built-in lifecycle handlers are described in more detail below.

Configuring Lifecycle Handlers

Lifecycle handlers are specified in the lifecycleManager block of a solution declaration (see Solution Registry). This block consists of two properties, start and stop which define arrays of individual lifecycle handler declarations: <syntaxhighlight lang="javascript">

   "lifecyceManager": {
       "start": [{...}, {...}, ...],
       "stop": [{...}, {...}, ...]
   }

</syntaxhighlight>

Using Regular Lifecycle Handlers

The lifecycle handlers are referred to in a solution declaration. This is the general format:

<syntaxhighlight lang="javascript">

   "lifecyceManager": {
       "start": [{
           "type": "lifecycle.action.function",
           "arg1": "some argument1",
           "arg2": true,
           (...)
       }],
       "stop": [{...}]
   }

</syntaxhighlight>

It should have a type that refers to what lifecycle handler to execute, and then an arbitrary number of key-value pairs for arguments to the lifecycle handler.

System Exec Lifecycle Handler

The System Exec lifecycle handler makes command line calls using nodejs' exec function. It has the type gpii.launch.exec and one argument:

  • command: the command to execute.

An example of usage is the following:

<syntaxhighlight lang="javascript">

   "lifecyceManager": {
       "start": {
           "type": "gpii.launch.exec",
           "command": "${{environment}.SystemRoot}\\System32\\Magnify.exe"
       },
       "stop": {...}
   }

</syntaxhighlight>

NOTE: In the command a reference to a dynamic variable - the SystemRoot environment variable is what is being referred to. When the lifecycle handler is executed, the ${{environment}.SystemRoot} will be replaced by value of the ENVIRONMENT variable SYSTEMROOT. There are a few of these dynamic variables available and they are described below.

GSettings Lifecycle Handler

The GSettings lifecycle handler is able to set values in Gnomes GSettings schemas. It should have the type gpii.gsettings.setSingleKey and takes three arguments:

  • schemaId: the schema that contains the desired key
  • key: the key for which to set the value
  • value: the new value the key should get

An example of usage is the following:

<syntaxhighlight lang="javascript">

   "lifecyceManager": {
       "start": {
           "type": "gpii.gsettings.setSingleKey",
           "schemaId": "org.gnome.desktop.a11y.applications",
           "key": "screen-magnifier-enabled",
           "value": "true"
       },
       "stop": {...}
   }

</syntaxhighlight>


Using Special Lifecycle Handlers

There are two special lifecycle handlers:

  • "setSettings" signals the settings handlers to set the settings. It is declared simply by using the string "setsettings"
  • "restoreSettings"' signals the special lifecycle handler that tells the settings handlers to set the setting

Example of their usage: <syntaxhighlight lang="javascript">

       "lifecycleManager": {
           "start": [ 
               "setSettings"
           "stop": [ {
               "restoreSettings", 
           ]
       }

</syntaxhighlight>

The special settings handlers can be combined with other lifecycle handlers: <syntaxhighlight lang="javascript">

       "lifecycleManager": {
           "start": [
               "setSettings",
               {
                   "type": "gpii.launch.exec",
                   "command": "gsettings set org.gnome.desktop.a11y.applications screen-magnifier-enabled true"
               }
           ],
           "stop": [
               {
                   "type": "gpii.launch.exec",
                   "command": "gsettings set org.gnome.desktop.a11y.applications screen-magnifier-enabled false"
               },
               "restoreSettings"
           ]
       }

</syntaxhighlight>

For information about configuring Settings Handlers, see Settings Handler.

Using Dynamic Variables

coming soon...

ENVIRONMENT variables

In the lifecycle actions in the solution registry, you can refer to ENVIRONMENT variables using the following syntax:

${{environment}variable}

So for example, if you have a lifecycle action in which you want to get the value of the TEMP environment variable, it would look like:

<syntaxhighlight lang="javascript"> {

   "type": "gpii.launch.exec",
   "command": "echo 'kill' > ${{environment}.TEMP}\\RW8Updates.dat"

} </syntaxhighlight>

Here "${{environment}.TEMP}" would evaluate to the value of the TEMP environment variable. If this was "c:\temp", the above lifecycle action would echo the string "kill" and write that to the file "c:\temp\RW8Updates.dat".

Refering to Windows Registry values

You can also refer to Windows REGISTRY values using the following syntax:

${{registry}BASEKEY\\path\\to\\registry\\key\\keyname}

So for example, if you have a lifecycle action in which you want to get the value of a registry entry which is on the basepath: "HKEY_CURRENT_USER", the path "Software\\Texthelp\\Read&Write10" and has the key "InstallPath" you would do:

<syntaxhighlight lang="javascript"> {

   "type": "gpii.launch.exec",
   "command": "\"${{registry}.HKEY_CURRENT_USER\\Software\\Texthelp\\Read&Write10\\InstallPath}\\ReadAndWrite.exe\""

} </syntaxhighlight>

So, if the value of the registry entry was "c:\Windows\Applications\RWG", the entire command would evaluate to "c:\Windows\Applications\RWG\ReadAndWrite.exe"