PAYARA-3880 Fixed JVM options as semi-colon separated list parameter

[jbee]

Description

When JVM options are passed to commands like the create-jvm-options command the options are compacted into a single String with : as delimiter between the options.

Depending on the view of the caller JVM options are lists or maps. Processing is partly as list, partly as maps. Even when the processing assumes maps a caller might conceptually use lists in which case the keys of an input map contain the full option including values, the map entry then is empty.

Dependencies

Lately changes were made in #3887, #3957 and #3536 to address other corner cases. One side effect was #3992.

Reviewer notes

This PR is the attempt to satisfy all requirements (including those of the referenced PRs/JIRA issues) with a general processing function that does not have corner case exceptions as they have shown to cause problems elsewhere.

To allow unit testing of the processing function I had to extract it to a class that is free of static references to facilities that aren't relevant for the test but would require some form of context initialisation. Therefore I extracted it to ResourceUtil.

Testing performed

Similar to the processing function the tests were moved to the appropriate test class for the new location. Existing tests were made into junit tests and extended with further test cases. The tests now cover 100% of the processing function.

For integration I further performed manual testing:

Admin GUI:

• edit -Xmx512m to -Xmx1024m, save
• add an option of type key=value, save
• remove the value part of the added option (keeping the = sign), save

Command line:
Using create-jvm-options as documented here https://docs.payara.fish/documentation/payara-server/server-configuration/jvm-options.html to try same key-values tested in admin GUI.

REST API:
Sending POST or PUT to http://localhost:4848/management/domain/configs/config/server-config/java-config/jvm-options):

• Header: Accept: application/json
• Header: X-Requested-By: GlassFish REST HTML interface
• Header: Content-Type: application/json
• Body: { "-client": "" } (and other key-values)

The effect needed to be verified in the domain.xml.

Note that REST API POST does replace the config with the posted body while PUT always adds. This is general behaviour that isn't very convenient and might even be considered for change.

Note also that command line strips escaping to early making it ineffective. E.g. -XX\:NewRatio\=2 is stripped to -XX:NewRatio=2 before the parameters are handled so it is split into -XX and NewRatio=2 (which is an illegal option). This is an most likely unreported error preexisting at least since 5.191. According to the documentation (link above) such escaping should have allowed to avoid splitting option values.

Note that adding an options of type key= at the end of the list in the admin GUI can lead to an exception when trying to split encountering an escape at the end of the input. This is most likely a defect in general input processing.

Further note that create-jvm-options does warn about -Xmx or -Xms already being set when adding them anew. This however is only a warning and both values will be contained. Due to the unpredictable nature of the JVM options bag in the config object the order of options can change with every change swapping the option that is effective in case of duplicate "keys".

[jbee]

jenkins test please

[cubastanley]

Tested locally, works as expected

[AlanRoth]

Tested locally, all good

[jbee]

jenkins test please

[Pandrex247]

I don't know if I did something weird or not, but I managed to set -XX\:NewRatio\=2 from the command line

[jbee]

@Pandrex247 Did run commands from shell (asadmin create-jvm-options ...) or first enter into asadmin and then go create-jvm-options? Maybe that can make a difference?