[fix] jetty configuration changes don't stick, and eventually crash eXist-db

[alanpaxton]

Description:

Updated jetty-http.xml and jetty-ssl.xml were being written by the configurator with a bad DTD, which on subsequent read by the configurator caused an exception, so that the NEXT versions of jetty-http.xml and jetty-ssl.xml were made empty. This then caused a startup crash.

1. Fix the DTD reference.

Also, configurator was reading the wrong field(s) for the http configuration, so

2. make configurator read the correct fields for jetty http configuration, so that subsequent edits of an already re-configured jetty don’t end up re-introducing the default (8080)

Reference:

Closes #4729

Type of tests:

Unfortunately it is not simple to automate this testing. We have built a test distribution with the changes, installed it (java -jar ./exist-installer/target/exist-installer-7.0.0-SNAPSHOT.jar) and confirmed through the use of ./bin/launcher.sh in the new installation that modifications of the jetty configuration are stored, restored and used on startup as the jetty ports. A distribution built without the change allowed us to reproduce the failed configuration changes, crashes and empty files produced in the initial problem report.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[adamretter]

LGTM. Thanks @alanpaxton

[duncdrum]

@alanpaxton all the steps you describe should be easy to test with the docker workflow on the CI here. Following the template for modifying conf.xml. In essence, modify file, start modified container, assert that change is applied, end container.

Please add a test

[adamretter]

@duncdrum How would you see using the Launcher Configuration GUI working from inside a Docker container in CI exactly?

[duncdrum]

@adamretter

Also, configurator was reading the wrong field(s) for the http configuration, so

make configurator read the correct fields for jetty http configuration, so that subsequent edits of an already re-configured jetty don’t end up re-introducing the default (8080)

does this only refer to the configurator of the initial launch agent, or to the configurations that is read whenever you start exist?

[alanpaxton]

The configurator that is started on initial, and whenever you run "System Configuration" from the (GUI) Menu Bar, is the same configurator code with the same problem.