Developers guide

55
doc-tar.gz
Packages the JavaDocs and content of the doc directory code into the
archive apt__V<version-key>/apt-docs__V<version-key>.tar.gz
6.5 Version synchronisation
The APT System is a very dynamic software application, software changes on the server are likely
to create incompatibilities with the client code. In addition to the flexibility of running multiple
versions of the server, it is also necessary to synchronise the client code, so we can guarantee
that the correct, corresponding version is run.
A significant portion of this problem is solved using JNLP and Java Web Start. A JNLP
configuration allows an indefinite number of clients, distributed anywhere on the Internet, to
automatically download and install the APT client application.
By omitting the <offline-allowed/> tag in the JNLP configuration file, the Web Start client is
forced to reload the up to date JNLP information from the web server. If this operation fails, Web
Start will not run the application.
Consequently the problem is simplified to that of ensuring that the JNLP configuration file is up to
date and matches the version of the server that is running. This is achieved very simply by
copying the apt-client.jnlp file to the Web Start web server whenever the server is started,
overwriting the previous jnlp configuration.
The runServer script, used to start the server on mistral, copies the corresponding apt-
client__V<version>.jnlp file to apt@mcba5/~apt/public_html/software/webstart/apt-
client.jnlp. Thus guaranteeing that any new clients started will be using the correct version. Note
that the apt-client__V<version>.jnlp is created at build time using the ant prepare target.
Every version or build has its own copies of all configuration files required to run the server.
The apt-client.jnlp file is generated at build time tagged with the version-key property
specified in the ant build.xml.
However, this elegantly simple solution is not completely correct. If the server is started after the
client software has loaded, there is no guarantee that the jnlp file used to start the client
corresponds to that of the server. This is unlikely to ever be a problem since restarting the server
while the client is logged in will cause the client software to fail, and attempting to login to an
incompatible version of the server is also likely to fail. Both of these scenarios will prompt the user
to restart the client, forcing JNLP configuration to be reloaded, and subsequently eliminating the
problem.
In the unlikely event of the client successfully logging in to a different version of the server a
runtime check can be performed. This is currently not implemented.