h2. Working with JBI artifacts
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 <artifact-file> [<configuration-file> | <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 space, 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 IDs and artifact file names.{tip}
h3. Deployment of an Artifact located in a Maven repository
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>*.
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}
> ./petals-cli.sh -y - << EOF
deploy /tmp
EOF
> ./petals-cli.sh -C
Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> deploy /tmp
Are you sure you want to deploy all artifacts of directory '/tmp'? (Y/n)
{code}
If the argument _<artifact-file>_ of the '_deploy_' command is a local directory, all artifacts of the directory are deployed. In this case, a confirmation is expected, except if the flag '_yes_' is set on the command line. A confirmation message is displayed in the mode console, except if the flag '_yes_' is set on the command line.
h3. Starting an Artifact
An artifact can be started by using the '_start_' command with the argument '_artifact_':
{code}
> ./petals-cli.sh -c start artifact [ <artifact-file> | [<artifact-type> <artifact-id>] ]
{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}
h3. Stopping an artifact
An artifact can be stopped by using the command '_stop_' with the argument '_artifact_':
{code}
> ./petals-cli.sh -c stop artifact [ <artifact-file> | [<artifact-type> <artifact-id>] ]
{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}
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 [ <artifact-file> | [<artifact-type> <artifact-id>] ]
{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}
h3. Bulk Undeployment and Stop
To undeploy several artifacts in one command, just put them in a local directory and execute the '_undeploy_' command:
{code}
> ./petals-cli.sh -y - << EOF
undeploy
EOF
> ./petals-cli.sh -C
Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> undeploy
Are you sure you want to undeploy all artifacts of the Petals node (Y/n) ?
{code}
If no argument is set on command '_undeploy_', all the artifacts are undeployed. In this case a confirmation is expected, except if the '_yes_' flag is set on the command line. A confirmation message is displayed in the console mode, except is the '_yes_' flag is set on the command line.
h3. Showing installed JBI artifacts
All the installed JBI artefacts can be listed using the command '_list \[<artifact-pattern> \[artifact-type\]\]_':
{code}
> ./petals-cli.sh -c list
petals-bc-soap Started BC
petals-se-bpel Started SE
soap-consume-provide Started SA
su-SOAP-EchoService-consume Started SU
su-SOAP-EchoService-provide Started SU
{code}
where:
* *<artifact-pattern>* 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.
* *<artifact-type>* is one of the following values: SL, BC, SE, SA, SU, used to restrict the returned list.
For each artifact, the command displays (caution to the padding):
* Its JBI identifier.
* Its current status.
* Its type (SL, BC, SE, SA, SU).
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] [ <artifact-file> | [<artifact-type> <artifact-id>] ]
{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
** Extended information:
*** List of embedded libraries
* 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)
** Extended information:
*** List of embedded libraries of the boostrap classpath
*** List of embedded libraries of the runtime classpath
*** List of needed shared-libraries, for each shared-library:
**** Its JBI identifier
**** The version of the shared library if available, extracted from its JBI descriptor
* 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:
*** For each service unit:
*** 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 '_stop_' command with the argument '_container_':
{code}
> ./petals-cli.sh -c stop container
{code}
h3. Shutdowning the container
The container can be shutdowned by using the command '_stop_' with the argument '_container_' and the parameter '_\--shutdown_'.
{code}
> ./petals-cli.sh -c stop container --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. A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line.
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
* Node1
** information
* 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 <logger-name> <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. "FINR 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 <regular expression>
logger1
logger2
...
{code}
{tip}Auto-completion is available on logger names.{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 '_\--all_' argument.
{code}
> registry-sync --all
<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}<sup>th</sup>{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 endpoint <endpoint-name-regexp> service <service-name-regexp> interface <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.
E-mail
...