Migration from previous scripts
While the interface of the previous gda command has been kept where possible for the main uses, there are differences to make it more consistent and predictable.
While these are the currently implemented commands, they are not fixed indefinitely and if there is a valid reason why alternative syntax would be more useful, it may be possible to accommodate it.
Starting and Stopping the server
Most of the time the servers are not stopped manually. Instead, gda servers is
used to restart the server, shutting down the server if it is already running.
This behaviour is unchanged.
server) to reflect that there is now only one server,
the previous servers name has been kept as an alias for
compatibility).
If a user wishes to stop the server but not restart it, or start it only if there is not a server already running, the command has changed
| Action | Previous | New Command |
|---|---|---|
| Start the server without stopping existing server | gda --start servers | gda server start |
| Shutdown the server without starting a new one | gda --stop servers | gda server stop |
| Restart the server (shutting down any existing one) | gda --restart servers or gda servers | gda server restart or gda server |
Motivation
By convention command options reflect the command they follow, given the
--start, --stop, --restart options do not apply to the other subcommands,
it did not make sense for them to be at the top level of the gda command.
The new gda command also adds additional server commands where it did not make
sense for start or stop to be options (eg status).
Setting Spring profiles
Spring profiles are used to enable or disable specific aspects of the server or client. There can be a configurable set of profiles enabled by default. With the new launcher, it has been easier to set and clear these profiles.
| Action | Previous | New Command |
|---|---|---|
| Add xyz to the default set of profiles | N/A This isn't currently possible | gda server start -p xyz |
| Disable the default profiles | gda servers --nospringprofiles | gda server start -P (or the more descriptive gda server start --no-default-profiles) |
| Replace the default profiles with abc and xyz | gda server --springprofiles 'abc,xyz' | gda server start -P -p abc -p xyz |
Motivation
Being able to add to the default profiles without overriding them was a big
motivation for this change. The previous command reserved -p for GDA profiles,
a feature that has not been used for several versions. Repurposing it for spring
profiles makes it much more convenient, while allowing repeated use to specify
multiple better follows conventions set by other commands. There is a more
verbose --profile option that behaves the same way if it's being used in
scripts where being more descriptive is beneficial.
Setting client workspace directory
The previous command had a --workspace option to specify an alternative
location for the client workspace directory. This allowed multiple clients to be
started on the same machine without clashing. This has been replaced with a
--tag option that creates the workspace in the same location but appends a
user provided tag to the directory name. This still allows multiple clients to
be run and makes it clear what each workspace was used for but prevents the user
having to provide a full path to a suitable workspace location.
| Action | Previous | New Command |
|---|---|---|
| Use a non-default client workspace | gda client --data /path/to/workspace/directory | gda server start --tag alt |
Motivation
This makes it simpler to use an alternative workspace while keeping all workspaces in a single place for consistency making it easier to go back to a previous workspace without having to know to specific directory.
Setting custom system properties
The previous scripts used GDA_CLIENT_VMARGS and GDA_SERVER_VMARGS variables
and passed them as they were to the relevant command. These were generally set
in the custom bash scripts for a beamline.
The new launcher has two approaches for custom system properties. For those that
should be set every time, there is the system section of the launcher
configuration (see configuration section
for details), and there is a -D option (to mirror the same option when calling
java).
Previous commands
$ export GDA_SERVER_VMARGS="${GDA_SERVER_VMARGS} -Dnew.property=value"
$ gda server
New command
$ gda server start -Dnew.property=value
Motivation
It makes it much easier to set system properties on the fly.
Debugging the server or client
The --debug flag to the server is still present but is now also required to
be after the component to start, ie gda server --debug and gda client --debug. The same is true for the equivalent --debug-wait flag.
There is now also a --debug-port option that allows the debug port to
specified instead of defaulting to 8000. This option requires either --debug
or --debug-wait to be present.
Motivation
Similar to the start and stop commands, it is more predictable for the flags and options to appear after the command they relate to.
gdaclient and gdaservers commands
These changes refer only the gda command provided on all beamlines. If
beamlines use gdaclient or gdaserver (or similar) scripts, these are not
changed although if they rely on the gda script they may need to be modified
if they use any of the features listed above.