ServiceConfigGuide re-orders ConfigEntries when merging

[drewfarris]

Given a configuration file like:

TEST_KEY = testValueA
TEST_KEY = testValueB

There are potentially places that are sensitive to the ordering of the ConfigEntries that are generated, such as coordination places. When running with a plain configuration file, the order is preserved, but when merging in a flavored configuration (or whenever else the merge flag is set to true in ServiceConfigGuide.handleNewEntry(...), the new ConfigEntries generated are inserted at position 0 in the serviceParameters list. As a result, the entries wind up in the list in the opposite order in which they were listed in the configuration file. This means it may be difficult to preserve/predict the order a series of configuration entries are returned by something like List<String> configG.findEntries("TEST_KEY")

In the case of the example above, a non-merge operation generates the order 'testValueA, testValueB' whereas a merged configuration operation produces the result of 'testValueB, testValueA'. The issue on merge may indeed be more complex than a simple re-ordering and deserves further investigation.

One portion of the code in question is from the ServiceConfigGuide.handleNewEntry(...) method

emissary/src/main/java/emissary/config/ServiceConfigGuide.java

Lines 289 to 293 in 03c58c0

	if (merge) {
	this.serviceParameters.add(0, anEntry);
	} else {
	this.serviceParameters.add(anEntry);
	}

Alternately, we could just make the statement that findEntries always returns the matching configuration options in non-deterministic order and rely on other methods for precisely ordering configuration entries.

It's not clear how pervasive the ordering assumption is throughout configuration files used in systems that depend on Emissary, so any changes related to this will require investigation.