Bug 1013886

These server details can be loaded from a JSON file on the server at /pressgang-ccms-config/servers.json. The following is an example of the format of this file.

 [
  {
     "serverId": 1,
     "serverName": "My Server",
     "serverGroup": "Default Servers",
     "restUrl": "http://myserver.com/pressgang-ccms",
     "reportUrl": "http://mybirtserver.com",
     "monitoringUrl": "http://myserver.com/pressgang-ccms/monitoring",
     "readOnly": false
  }
 ]

If the server does not respond with a valid JSON file, the last valid JSON file saved to local storage will be used.

If there is no valid JSON file in local storage, the default locations for the server will be used.

This system requires a project to server up static content. https://github.com/pressgang-ccms/PressGangCCMSConfig is an example of this.

Fixed in 201311191000

This can be verified on the dev server.

You can also copy the file welcome-content/pressgang-ccms-config/servers.json assuming you don't have a ROOT.war file, and you have not disabled the welcome content.

Verified that the UI will now read from a servers.json file located at /pressgang-ccms-config/servers.json. If the servers.json file doesn't exist then it will use the default settings which point the rest server to the same host as the UI. It also groups the servers together properly so that the fail over will occur.

However if the servers.json contains no valid servers (ie the restServer value is missing) then the ListBox is populated with no values, when it probably should revert to the default.

Another problem is that the UI will save invalid configs to local storage as well (this happens as soon as the servers.json is returned), so if I had a valid version previously then did a minor update that was invalid, it wouldn't revert to the last valid settings and instead would fall through to the default settings.

I have added some validation checking to make sure that every server defined in the servers.json file has all the required fields, and that at least one server is defined. If that is not the case the settings are not saved into local storage and the server details are loaded from any previously saved settings, or use the default.

Note that my initial implementation was flawed. Getting the server details is now an inherently asynchronous operation because the details may be sourced from an external file.

This means that every call to ServerDetails.getSavedServer() has been changed from a synchronous call that returned the server details to an asynchronous callback.

This has no practical effect since once the server details are loaded for the first time, the "asynchronous" callback actually operates as a synchronous call (i.e. it calls the callback immediately). And the server details are first loaded when the app is opened and before any part of the UI is displayed.

I'm making a note of it here because of the number of calls to ServerDetails.getSavedServer() that had to be changed.

Using an invalid JSON config file appears to completely kill the UI now. All that happens is that an error about being unable to parse the file is logged and then you get a plain white screen.

The above is caused by the default settings not executing the callback.

When using multiple servers the list that is populated is always the same server now. This is caused my the populate method getting all the servers and then for each one of them only getting the "saved" server.

Other than the above issue I've verified the following:

- Invalid JSON will fall-back to local storage and then back to the defaults (except the defaults don't call the callback).
- If a required property is missing from a server definition, the entire servers.json is rejected and it will fall-back.
- If no servers are defined then it will fall-back.

Changing servers also doesn't work with the new implementation.

Ignore the above statement as upon looking into it more, the servers are changed however the AlertBox doesn't block the page from reloading so you don't see the warning message when switching between two different server groups.

The above instances should now be fixed and is currently live on the dev server.