{section}
{column}

h1. Introduction

Petals CLI is a command line client to administrate a set of Petals nodes.
Petals CLI has 4 interaction modes:
* *Interactive Mode:* [in this mode|#Interactive console], the user types in commands directly in the shell.
* *Scripting Mode:* [in this mode|#Execution of a Petals script file], Petals CLI executes a script file that contains Petals CLI commands.
* *Executable Mode:* [in this mode|#Execution of a Petals CLI command directly on the command line], Petals CLI is launched with a command as an argument.
* *Redirection Mode:* [in this mode|#Execution of an inlined Petals script], Petals CLI takes the commands to execute from the standard input.

To work, Petals CLI needs to establish a connection with a Petals node.
The connection is a JMX connection (see the credentials defined in the _topology.xml_ file of Petals).

{warning}
Petals CLI *1.0.0* works with Petals *4.0*, but may also work with Petals 3 versions.
Petals CLI *2.0.0* works with Petals *4.1* and higher, but may also work with Petals 3 versions.
{warning}
{column}
{column:width=40%}
{panel:title=Table of contents}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}

h1. Use Cases

{gliffy:name=Petals_CLI_Use_Cases|align=center|size=L|version=3}

h1. Usage of Petals CLI

h1. Petals CLI: the Basis

h2. Installing Petals-CLI

Make sure you have downloaded petals-cli.x.x.zip.
Unzip it wherever you want to install it.

h2. Petals CLI capabilities about script and shell usages

h3. Interactive console

Launching Petals CLI with the following command line starts an interactive console with a prompt where the user can enter commands.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli>
{code}

On Windows, to be able to launch Petals CLI by a double-click, this command is wrapped by another script: *petals-cli-console.bat*.
On Linux, there is no wrapper script but a shell alias can be created. Next, this alias will be automatically created by a RPM or debian package.

h3. Execution of a Petals CLI command directly on the command line

Launching Petals CLI with the following command line executes the command specified on the command line.
{code}
> ./petals-cli.sh -c -- <command> <command-args>
{code}

h3. Execution of a Petals script file

Launching Petals CLI with the following command line executes the commands from the specified Petals script.
{code}
> ./petals-cli.sh <filename>
> ./petals-cli.sh --file <filename>
{code}

{info}A Petals script is text file containing commands supported by Petals CLI, and comments. Comments start by '{{#}}', optionally preceded by space(s).{info}

h3. Execution of an inlined Petals script

Launching Petals CLI with the following command line executes commands provided through the standard input ("stdin").

{code}
> cat <filename> | ./petals-cli.sh -
> cat <filename> | ./petals-cli.sh --file -
> ./petals-cli.sh - << EOF
<command1> <command1-args>
<command2> <command2-args>
EOF
> ./petals-cli.sh --file - << EOF
<command1> <command1-args>
<command2> <command2-args>
EOF
{code}

h2. Getting help

h3. Getting help on command line options and arguments

The help on command line options and arguments is available through the '_\-H_' option. A text containing options, arguments and available commands is displayed according to the usage defined above.
{code}
> ./petals-cli.sh -H
{code}

h3. Getting help on commands from the command line

The help on a command is available by using the command '_help_'. A usage and a description of the command is displayed:
{code}
> ./petals-cli.sh -c -- help <command>

usage: <command> <command-arguments>

<command description>

>
{code}
where:
* {{<command>}} is the command for which we want to get help.
* {{<command-arguments>}} is the list of arguments for the command.
* {{<command-description}} is a description of the command.

h3. Getting help on available commands and on a command in interactive mode

The list of available commands is available by using the command '_help_' without argument.
Help about a command is available by using the '_help_' command. Command's usage and description are then displayed.
{code}> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> help

Available commands:
deploy Deploy and start a JBI artifact in petals container.
exit Exit this shell.
help Display this help message or help for a specific command.
...

For help on a specific command type:
help <command>

petals-cli> help <command>

usage: <command> <command-arguments>

<command description>

petals-cli>
{code}
where:
* {{<command>}} is the command for which we want to get help.
* {{<command-arguments>}} is the list of arguments for the command.
* {{<command-description}} is a description of the command.

h2. Getting the version of Petals CLI

To get the version of Petals CLI, the version of the JVM running Petals CLI, and its operating system, use the '_\-V_' option:
{code}
> ./petals-cli.sh -V
Petals JMX Command Line Interface 1.1.0-SNAPSHOT
Java(TM) SE Runtime Environment 1.6.0_26-b03
Linux 3.0.0-16-generic-pae
{code}

h2. Return codes of Petals CLI

h3. Return code on error parsing mode options

If Petals CLI is not able to determine the mode (interactive, scripting, executable or redirection) to use from arguments, the return code will be 1.

h3. Return code of Petals CLI launched in interactive mode

Petals CLI launched in interactive mode will exist always with the return code 0, even if error occurs executing a command.
If an error occurs during a command execution or parsing:
* The error message is displayed.
* Petals CLI is not interrupted, the user can enter other commands.

h3. Return codes of Petals CLI launched in executable mode

h4. Return code on parsing error of the command arguments

When there is an no error about options and arguments of the command, the return code of Petals CLI is 1.

h4. Return code on command execution

When there is an no error about the command execution, the command is interrupted and the return code of Petals CLI is 2.

h4. Return code on successful command execution

When there is no error about options, arguments and execution of a the command, the return code of Petals CLI is the return code of the command

h3. Return code of commands

All commands return the return code 0 when the execution succeeds, and 1 when the execution fails. Except the command '{{system}}' that returns the return code of the system command invoked.

h3. Return codes of Petals CLI launched in scripting modes

h4. Options and arguments parsing of command

When using the script mode or inlined mode, parsing errors (invalid options and/or arguments) result in an interruption of Petals CLI.
The return code 1 then pushed back.

h4. Error management of a command read from stdin or a file

If an error occurs during the execution of a flow of commands:
* The command that has thrown the error is interrupted.
* The return code of the command can be checked using the commands _isParsingErrorReturned_, _isExecutionErrorReturned_, _isNoErrorReturned_, the ternary conditional operator, and the _lastErrorCode_ attribute.
{code}
> ./petals-cli.sh - << EOF
deploy <artifact-url>
isNoErrorReturned ? listartefacts : exit lastErrorCode
EOF
{code}

\\
Note:
* The return values of command {{isParsingErrorReturned}}, {{isExecutionErrorReturned}} and {{isNoErrorReturned}} are reset when invoking another command. Only the error of the last command execution can be checked.
* The attribute {{lastErrorCode}} is an argument of the command {{exit}} to return the return code of the last executed command.

h2. Exit from the Console mode

To exit the console mode, use the '_exit_' command.
If a number is set as an argument, it is used as return code. Otherwise, the 0 is returned.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> exit
> echo $?
0
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> exit 1
> echo $?
1
{code}

h2. Petals CLI Preferences

It is possible to define preferences in Petals CLI.
The preferences are defined a properties file, as key/value pairs.
By default, this file is located at _$PETALS_CLI_HOME/conf/preferences.properties_.

However, it is possible to move this file somewhere else thanks to an environment variable.
_$PETALS_CLI_PREFS_ is the variable environment that points to the location of the preferences file.

This file contains a set of keys in several sections:
* section 'Global preferences':
** *alias.default*: the default alias to use (required).
** *user.lang*: the language to use in Petals CLI.
*** This property is optional. If not set, OS settings are used. If the OS language setting is not supported, then English is used.
*** If the value is specified and not supported, then English is picked up.
*** French and English are the two languages that must be supported. Others are optional (but contributions are welcome).
* section defining aliases. An alias identifies all the properties of a connection. An alias is defined as following:
** *<alias>.host*: the host of the default Petals node (required).
** *<alias>.port*: the JMX port of the default Petals node (required).
** *<alias>.username*: the JMX user name for the default Petals node (optional).
** *<alias>.password*: the JMX password for the default Petals node (optional).
When optional keys are not defined, Petals CLI will ask for their values manually (or you will have to use the right options with the commands).
If the file does not exist, or that _$PETALS_CLI_PREFS_ points to an invalid location, Petals CLI will use default settings when possible. Otherwise, it will display an error message.

\\
For a server, the *user* and *password* must both be set or both be absent.
An error message is displayed if only one of them is specified.

\\
The server alias must be unique in the properties file.
If a server alias is used twice, an error message will be displayed.

\\
Initial content of the file:

{quote}
# The default server / connection
alias.default = default

# The connection properties of the 1st server
default.host = localhost
default.port = 7700
default.username = petals
default.password = petals
{quote}

h1. Connection to a Petals node

h2. Connection options from the command line

All the required parameters for a JMX connection must be configurable on the command line as options:
{code}
> ./petals-cli.sh -h <host> -n <port> -u <user> -p <password> -c -- <command>
> ./petals-cli.sh -h <host> -n <port> -u <user> -p <password> -C
petals-cli@<host1>:<port1>>
{code}

\\
An alias can also be used.
{code}
> ./petals-cli.sh -a <alias> -c -- <command>
> ./petals-cli.sh -a <alias> -C
petals-cli@<host1>:<port1>>
{code}

h2. Interacting with several Petals nodes without exiting Petals CLI

In interactive mode or script mode, we should be able to close a connection and open another one without leaving Petals CLI. This is achieved with the '_connect_' and '_disconnect_' commands. If no argument is set on the '_connect_' command, default values are used. These default values are specified in the preferences file. If a connection already exists, the '_connect_' command will realize a disconnection before to establish the new connection.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect -h <host1> -n <port1> -u <user1> -p <password1>
Connected on <host1>:<port1> with '<user1>'
petals-cli@<host1>:<port1>> disconnect
petals-cli> connect -a <alias>
Connected on <host1>:<port1> with '<user1>'
petals-cli@<host1>:<port1>> disconnect
petals-cli> connect -h <host2> -n <port2> -u <user2> -p <password2>
Connected on <host2>:<port2> with '<user2>'
petals-cli@<host2>:<port2>> connect
petals-cli@<host2>:<port2>> Would you like to connect to <default-user>:*****@<default-host>:<default-port>? (y/n)
y
petals-cli@<default-host>:<default-port>>
{code}

h2. Default connection

By default (if no argument or option is set).
In console mode, the connection is established with the values given in the preferences file.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
petals-cli> Would you like to connect to <default-user>:*****@<default-host>:<default-port>? (y/n)
y
petals-cli@<default-host>:<default-port>>
{code}

The confirmation can be skipped by adding the '_yes_' argument to the command.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect -y
petals-cli@<default-host>:<default-port>>
{code}

In command line mode, if no argument or option is set, a connection is established with the values defined in the preferences file.

{code}
> ./petals-cli.sh -c -- stop
{code}

{tip}This is necessary to easily stop a local container{tip}

In script mode, the connection is established with the values defined in the preferences file.
{code}
> ./petals-cli.sh - << EOF
connect
EOF
{code}

If the preferences file does not exist and that _connect_ was invoked without an argument, the command returns the error code 2.

h2. Security

For security reasons, a Petals CLI user may decide that there should be no default connection.
In that case, he may decide to delete the preference file, so that any user will have to type in the right information.
If the preference (properties file) does not exist, Petals CLI displays an error message.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
No default connection is available. Use 'help connect' for more information.
{code}

\\
Another possibility is that the user allows to record a default host and port but not the credentials.
In that case, Petals CLI will ask the user to type in the credentials.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
petals-cli> Would you like to connect to <default-host>:<-default-port>? (y/n)
y
petals-cli> Username: wrong-username
petals-cli> Password: right-pwd
Invalid credentials.
petals-cli> Retry? (y/n)
y

petals-cli> Username: right-username
petals-cli> Password: wrong-pwd
Invalid credentials.
petals-cli> Retry? (y/n)
y

petals-cli> Username: right-username
petals-cli> Password: right-pwd
petals-cli@<default-host>:<-default-port>>
{code}

h2. Error Messages

{tip}Error messages should be written in active form.
Negative forms should be avoided.{tip}

\\
The preferences file does not exist.
The connect command results in the following error message.

{quote}No default connection is available. Use 'help connect' for more information.{quote}

\\
The preferences file is invalid (missing property, or duplicate alias...).
The connect command results in the following error message.

{quote}The preferences file contains <N> error(s).
- Error 1
- Error2{quote}

\\
Duplicate Alias.
{quote}The alias '<alias>' can only be used once.{quote}

\\
Missing property.
{quote}The property '<property>' is missing.{quote}

\\
Only *user* was specified for a server.
{quote}The credentials for '<alias>' are invalid: add the password or remove the user.{quote}

\\
Only *password* was specified for a server.
{quote}The credentials for '<alias>' are invalid: add the user or remove the password.{quote}

h1. Administration Commands

h2. Working with JBI artifacts

h3. Artifact lifecycle managed by PetalsCLI

{gliffy:name=Artifact lifecycle of PetalsCLI|align=center|version=4}

h3. Deploying and Starting an Artifact at once

Petals CLI is able to deploy and start a JBI artifact without distinction between shared-library, component and service assembly using the following command:
{code}
deploy -u <artifact-file> [-f,--file <configuration-file> | -D <configuration-properties>]
{code}
where:
* *<artifact-file>* is the local file name or the URL of the artifact to install or deploy and start
* *<configuration-file>* is the local file name or the URL of the properties file used to configure the artifact. This argument is used only if the artifact is a component. It has no sense for other artifacts. This argument is exclusive with {{<configuration-properties>}}.
* *<configuration-properties>* is a list of '_<property-name>=<property-value>_', separated by a comma, where _<property-name>_ is the name of the property to configure with _<property-value>_. This argument is used only if the artifact is a component. It has no sense for other artifacts. This argument is exclusive with *<configuration-file>*.

{tip}Auto-completion is available on artifacts identifiers and artifact file names.{tip}

If the artifact to deploy is:
* a component:
** if its component installer is already loaded (the component is not installed), then the command '{{deploy}}' will unload the component installer, reload a new one and continue the lifecycle (configuration, installation and start),
** if the component is installed:
*** if the component is shutdown, then the command '{{deploy}}' will uninstall the component, unload the component installer, reload a new one and continue the lifecycle (configuration, installation and start),
*** otherwise an error occurs, use command '{{undeploy}}' to fix it.
* a service assembly:
** if the SA is already deployed and in state 'SHUTDOWN', then the command '{{deploy}}' will undeploy the service assembly, before to re-deploy a new one,
** otherwise an error occurs, use command '{{undeploy}}' to fix it.


h3. Deployment of an Artifact located in a Maven repository

{warning}Not available. Coming soon !{warning}

Petals CLI is able to deploy and start a JBI artifact located into a Maven repository by using the following command:
{code}
deploy <maven-artifact> [<configuration-file> | <configuration-properties>]
{code}
where:
* *<maven-artifact>* is the Maven identifiers of the artifact to install: _group-id:artifact-id:version\[:classifier\]_. If required, the Maven repository can be defined in the Maven configuration file ($HOME/.m2/settings.xml)
* *<configuration-file>* is the local file name or the URL of the properties file used to configure the artifact. This argument is used only if the artifact is a component. It has no sense for other artifacts. This argument is exclusive with {{<configuration-properties>}}.
* *<configuration-properties>* is a list of '_<property-name>=<property-value>_', separated by a white character, where _<property-name>_ is the name of the property to configure with _<property-value>_. This argument is used only if the artifact is a component. It has no sense for other artifacts. This argument is exclusive with *<configuration-file>*.

Same remarks about lifecycle of the deployment from an URL are applicable for the deployment from a Maven artifact.

h3. Bulk Deployment and Start

To deploy and start several artifacts in one command, just put them in a local directory and execute the command '_deploy_':
{code}
deploy -b,--bulk <url|file>
{code}
{code}
> ./petals-cli.sh -y - << EOF
deploy -b file:///tmp
EOF
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> deploy -b /tmp
{code}

If the argument _<artifact-file>_ of the '_deploy_' command is a local directory, all artifacts of the directory are deployed.
{note}Only the protocol 'file' is available.{note}

h3. Starting an Artifact

An artifact can be started by using the '_start-artifact_' command:
{code}
> ./petals-cli.sh -c -- start-artifact [ -u <artifact-file> | -a <artifact-id> [<artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL of the artifact to start.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to start.
* *<artifact-id>* is the JBI identifier of the artifact to start.

{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

If the artifact to start is a component or a service assembly, the command '{{start-artifact}}' will succeed only if the artifact state on Petals ESB side is 'STOPPED' or 'SHUTDOWN', otherwise on error will occur.

h3. Stopping an artifact

An artifact can be stopped by using the command '_stop\-_{_}artifact_':
{code}
> ./petals-cli.sh -c -- stop-artifact [ -u <artifact-file> | -a <artifact-id> [<artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL of the artifact to stop.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to stop.
* *<artifact-id>* is the JBI identifier of the artifact to stop.

{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

If the artifact to deploy is a component or a service assembly, the command '{{stop-artifact}}' will succeed only if the artifact state on Petals ESB side is 'STARTED', otherwise on error will occur.

h3. Undeploying and Stopping an Artifact at once

Petals CLI is able to stop and uninstall/undeploy a JBI artifact without distinction between shared-library, component and service assembly using the following command:
{code}
undeploy [ -u <artifact-file> | -a <artifact-id> [<artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL of the artifact to undeploy.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to undeploy.
* *<artifact-id>* is the JBI identifier of the artifact to undeploy.

{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

No lifecycle error can occur. Whatever the artifact state, the command 'undeploy' will adapt to it to realize the undeployment. In particular, if the artifact is in state 'STOPPED', it will be undeployed without confirmation and the user will be responsible to re-deploy it.

h3. Bulk Undeployment and Stop

The undeployment command is able to stop and uninstall/undeploy several JBI artifact in one shoot using the bulk mode:

{code}
undeploy [ -b [<artifact-directory>] ] [ -y ]
{code}
where *[<artifact-directory>* is a local directory name or the URL containing archives of artifacts to undeploy.

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- undeploy -b
> ./petals-cli.sh -c -- undeploy -b -y
> ./petals-cli.sh -c -- undeploy -b
ERROR on command 'undeploy': A confirmation is required. Use option: : '-y'
{code}

If the directory, containing artifacts to undeploy, contains an artifact that is not deployed, a warning is displayed, no error occurs and the undeployment of other artifacts continues.
If an error occurs during the undeployment of an artifact, the bulk undeployment is interrupted.


h3. Showing installed JBI artifacts

All the installed JBI artefacts can be listed using the command '_list \[-p <artifact-pattern> \] \[-t artifact-type\]_':
{code}
> ./petals-cli.sh -c -- list
petals-sl-mysql Installed SL
petals-bc-soap Loaded BC
petals-se-bpel Started SE
soap-consume-provide Started SA
su-SOAP-EchoService-consume SU
su-SOAP-EchoService-provide SU
{code}
where:
* {color:#000000}*<artifact-pattern>*{color} {color:#000000}is an optional RegExp pattern to filter the content of the returned list. All the returned JBI artifacts must have a JBI identifier matching the pattern. If no pattern is defined, all the installed artifacts are returned.{color}
* {color:#000000}*<artifact-type>*{color} {color:#000000}is one of the following values: SL, BC, SE, SA, SU, used to restrict the returned list.{color}

The returned list is ordered:
* firstly, according to the artifact type: SL, BC, SE, SA, SU,
* and secondly the alphabetical order is applied.

For each artifact, the command displays (caution to the padding):
* Its JBI identifier.
* Its current status:
** {{Loaded}}, available only for component, the installer is loaded but the component is not installed
** {{Started}}
** {{Stopped}}
* Its type (SL, BC, SE, SA, SU).

{tip}As the SU lifecycke can't be modified through the JMX API, there is no interest to display the SU status (it's the same as the status of its SA).{tip}

h3. Getting information about an Artifact

Information about a JBI artifact can be got with the '_show_' command:
{code}
> ./petals-cli.sh -c -- show [-e] [ -u <artifact-file> | -a <artifact-id> [<artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL of the artifact to show.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to show.
* *<artifact-id>* is the JBI identifier of the artifact to show.

The '-e' option displays extended information.

Displayed information includes:

* For a shared library:
** Its JBI identifier
** The version of the shared library if available, extracted from its JBI descriptor
** If the shared library was built with Maven, its Maven version extracted from Maven metadata
** {color:#ff0000}Extended information:{color}
*** {color:#ff0000}List of embedded libraries (coming next){color}


* For a component (BC or SE):
** Its JBI identifier
** Its type: binding component or service engine
** If the component was built with Maven, its Maven version extracted from Maven metadata
** Its state (not-loaded, loaded, installed, started, stopped, shutdown)
** {color:#ff0000}Extended information:{color}
*** {color:#ff0000}List of embedded libraries of the boostrap classpath(coming next){color}
*** {color:#ff0000}List of embedded libraries of the runtime classpath(coming next){color}
*** {color:#ff0000}List of needed shared-libraries, for each shared-library(coming next):{color}
**** {color:#ff0000}Its JBI identifier{color}
**** {color:#ff0000}The version of the shared library if available, extracted from its JBI descriptor{color}


* For a service assembly:
** Its JBI identifier
** If the service-assembly was built with Maven, its Maven version extracted from Maven metadata
** Its state (not-deployed, deployed, started, stopped, shutdown)
** List of embedded service-units (displayed using their JBI identifiers)
** Extended information (replace the previous list of embedded service-units):
*** For each service unit embedded:
*** Its JBI identifier
*** Its target component (displayed using its JBI identifier)

{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Interrupting a flow of commands

A flow of commands can be interrupted by using the '_exit_' command. If a number is set as argument, it is used as return code. The argument '_lastErrorCode_' is used as return code value of the last executed command. Otherwise, 0 is returned to the shell.
{code}
> ./petals-cli.sh -y - << EOF
deploy /tmp/my-artifact.zip
exit lastErrorCode
EOF
{code}

h3. Ending a flow of commands

When the end of a flow of commands is reached, if the last command is not '_exit_', the '_exit lastErrorCode_' command is implicitly executed.
{code}
> ./petals-cli.sh -y - << EOF
deploy /tmp/my-artifact.zip
EOF
echo $?
0
{code}

h2. Working with the Container

h3. Getting the versions related to a Petals node

To get the version of a Petals node, the version of the JVM running Petals node, and its operating system, use the '_version_' command:
{code}
> ./petals-cli.sh -c -- version
Petals JBI Container 3.1.4-SNAPSHOT
Java(TM) SE Runtime Environment 1.6.0_26-b03
Linux 3.0.0-16-generic-pae
{code}

h3. Stopping the container

The container can be stopped by using the command '_stop_':
{code}
> ./petals-cli.sh -c -- stop
{code}

h3. Shutdowning the container

The container can be shutdowned by using the command '_stop_' and the parameter '_\--shutdown_'.
{code}
> ./petals-cli.sh -C
petals-cli@host:port> stop --shutdown
Are you sure you want to shutdown the container? (y/n)
{code}

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- stop --shutdown
> ./petals-cli.sh -c -- stop --shutdown -y
> ./petals-cli.sh -c -- stop --shutdown
ERROR on command 'stop': A confirmation is required. Use option: : '-y'
{code}

h3. Getting the topology

When connected to a container, it is possible to get information about the topology this node is part of.

{code}
petals-cli@host:port> topology-list
Domain: Domain 1
Subdomain: SubDomain 1
* Container: Node1
** information

* Container: Node2
** information

Subdomain: SubDomain 2
...
{code}

\\
This command shows a set of Petals nodes, sorted by domain and sub-domains, each node having the following information:
* Container name
* Node type (master or slave)
* Host
* Node ports

h3. Getting the server properties

When connected to a container, it is possible to get all the values defined in its *server.properties* file.

{code}
petals-cli@host:port> properties-list
Key1: value1
Key2: value2
...
{code}
where "keyN" and "valueN" are the keys and values defined in the *server.properties* file of this container.

h3. Changing logger levels

On a container, it is possible to change the level of a logger.
{code}
petals-cli@host:port> logger-set -n <logger-name> -l <level>
The log level was succesfully changed.
{code}

In case of error, the error message is "The log level could not be changed.", followed by a detailed message (e.g. "FINER is not a valid log level").

\\
To get all the available loggers, use loggers without any argument.
{code}
petals-cli@host:port> loggers
logger1
logger2
...
{code}

\\
You can also use a regular expression to filter the candidate results.
{code}
petals-cli@host:port> loggers -p <regular expression>
logger1
logger2
...
{code}

{tip}Auto-completion is available on logger names and log levels.{tip}

h2. Working with the Service Registry

{note}Qualified names, like service and interface names, are written as follows:\{namespace-uri\}local-part.{note}

h3. Synchronizing the registry

A synchronization of the registry on a specific node can be done with the '_registry-sync_' command:
{code}
> registry-sync
Synchronization is done
{code}

\\
A synchronization of all the topology nodes can be done with the same command and the '_\-a_' argument.
{code}
> registry-sync -a
<Progress Report (as a percentage)>
Synchronization is done
{code}

\\
{note}Global synchronization is done in two passes:
* Each slave declares its end-points to the master node (n-1 synchronizations, where n is the number of nodes in the topology).
* Each slave gets the master end-points (start from the n-2{html}^th{html} node until we get back to the first slave).
{note}

The response message is displayed in console mode only.

h3. Showing the registry's full content

The full content of the registry can be dumped by using the '_registry-list_' command:
{code}
petals-cli> registry-list
Endpoints:
<endpoint-name-1>: <endpoint-1-characteristics>
<endpoint-name-2>: <endpoint-2-characteristics>
Services:
<service-name-1>:
<endpoints-list>
<service-name-2>:
<endpoints-list>
Interfaces:
<interface-name-1>:
<endpoints-list>
<interface-name-2>:
<endpoints-list>
{code}

where:
* <endpoint-name-x> is an endpoint name.
* <endpoint-x-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-x> is a service name.
* <interface-name-x> is an interface name.
* <endpoints-list> is the list of endpoint name implementing the interface or service.

h3. Filtering the registry's full content

The content of the registry can be dumped by using the '_registry-list_' command.
It is however possible to filter the dumped result.
{code}
petals-cli> registry-list \[-e <endpoint-name-regexp>\] \[-s <service-name-regexp>\] \[-i <interface-name-regexp>\]
Endpoints:
<endpoint-name>: <endpoint-characteristics>
Services:
<service-name-1>:
<endpoint-name>
<service-name-2>:
<endpoint-name>
Interfaces:
<interface-name-1>:
<endpoint-name>
<interface-name-2>:
<endpoint-name>
{code}

where:
* *<endpoint-name-regexp>* is a regular expression used as filter on the full end-point name.
* *<service-name-regexp>* is a regular expression used as filter on the full service name.
* *<interface-name-regexp>* is a regular expression used as filter on the full interface name.

In the result:
* <endpoint-name> is the endpoint name.
* <endpoint-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-x> is the services associated to the specified endpoint.
* <interface-name-x> is the interface names associated with the specified endpoint.

The parameter order (endpoint, service, interface) does not matter.
All are optional. If none is specified, the entire regitry content is dumped.

h2. System Commands

Petals CLI can directly execute system commands.
To achieve it, the system command is an argument of the '_system_' command.

{code}
petals-cli> system <system-command>
{code}

As an example,

{code}
petals-cli> system pwd
{code}

displays the directory in which Petals CLI runs.
The return code of the wrapping command is the return code of the system command.

h1. Advanced usage

h2. Logging in Petals CLI

Petals CLI is provided with a default Java Logging configuration. This configuration displays logging trace as following:
{code}
<LEVEL>: <message>
{code}
where <LEVEL> is the international label of the logging trace level, except for the level '{{SEVERE}}' which is always '{{ERROR}}'. By default, only levels '{{SEVERE}}' and '{{WARNING}}' are printed.

The default configuration can be overridden using the system property '{{java.util.logging.config.file}}' to set into the launching script '{{$PETALS_CLI_HOME/bin/petals-cli.sh}}' or '{{%PETALS_CLI_HOME%\bin\petals-cli.bat}}'. An sample configuration is available in file '{{$PETALS_CLI_HOME/conf/petals-cli-logging-sample.properties}}'

h2. To add your custom command

Petals CLI is provided with an API to add your own command.

h3. Writing your command

To create a new custom command, just create a new Java class that *IMPLEMENTS* the interface {{org.ow2.petals.cli.api.command.Command}}.
To be auto-discovered, your command *MUST* be declared in a resource named '{{META-INF/service/org.ow2.petals.cli.api.command.Command}}' (put the class name with the package part in this file).

If the new command needs third party products in addition of the ones already provided by Petals CLI, they *MUST* be installed with your command.
{warning}No classloader isolation is available between commands, pay attention to versions of third-party products. They MUST match the version of those provided with Petals CLI or those custom commands.{warning}

h3. Custom command installation

To install your command just put all needed JAR files in the directory {{$PETALS_CLI_HOME/extensions}}.

h1. Known Problems

h2. Error about missing options

For commands requiring at least one option, an error can occur if the operand flag ({{'--'}}) is missing:
{code}
> ./petals-cli.sh -h localhost -n 7700 -u petals -p petals -c -- deploy -u file:///.../my-archive.zip
ERROR on command 'deploy': Missing option(s):b, u
usage: deploy [-b <url> | -u <url>] [-D
<property1=value1,property2=value2> | -f <configuration-file>]
{code}
This is due to the option overriding: the command deploy and Petals CLI have the same option: {{\-u}}. Both {{\-u}} are processed by Petals CLI option parsing. Just add {{'--'}} before the command to exclude the second {{'u'}} of the Petals CLI option parsing. So it will be available for the command option parsing.