AppConfig instance variables need to be made volatile

[at055612]

We need to add volatile to all the props as these config singletons are being read and updated by multiple threads so memory effects are a possibility, though slight, given the frequency of config changes.

Need volatile on all instance variables except those of a type that extends AbstractConfig.

[at055612]

The alternative to this is to change to using immutable config objects.

We will need to change all config classes to have a @JsonCreator ctor, make all props final, remove all setters and add a no args ctor that will create the obj will all the default values. Depending on how we build objects from the yaml we may want to replace all primitives with boxed versions and the full args ctor to replace any nulls with the defaults.

We will need to inject config objects using providers. The providers will use some object that holds a hashmap of <Class, ? extends AppConfig> to get the instance to inject. The hashmap will be populated by:

1. Walk a vanilla AppConfig tree to establish what all the default values are and set up the globalPropertyMap.
2. Parse the yaml file (see below) to establish what the yaml overridden values are and to set those values in the globalPropertyMap
3. Read all the db props and set any db overrides in the globalPropertyMap
4. Use the globalPropertyMap to build a full object tree using all the effective values, putting each new object in a new class keyed hashmap, then swap out the previous hashmap with the new one.

To parse the sparse yaml file we may be able to do it manually using objectMapper.readTree to walk the sparse file. This way we don't have to worry about jackson's handling of null/default values when mapping to our POJOs. We can just get the value from the yaml file and if it is different to what we know the default to be then set it as a yaml override. If we stick with using mapping to POJOs from the file then we will need to ensure all POJOs use boxed types.

In order to create instances of config objects using the full args ctor we will need to use reflection to look at the @JsonProperty annos on the ctor to establish the ctor arg order so we can call it with all the right prop values.

All classes that inject config may need to be changed to inject a provider instead, depending on whether the class is short lived or not. Also need to change uses of the config to potentially get from the provider first rather than holding an instance of the config on its instance so it is always using up to date config. This does mean each call to get will invoke a hashmap lookup so for some high performance applications holding a local temporary copy may be needed.

[at055612]

Some code is on branch use-boxed-primitives

[at055612]

This is the preferred pattern for a config class

@JsonPropertyOrder(alphabetic = true)
@JsonInclude(Include.NON_NULL)
public class XConfig extends AbstractConfig {

  @JsonProperty // Optional unless we need a custom name
  private final Integer i;

  // no args ctor relies on creator ctor for defaults
  public XConfig() {
    return this(null);
  }

  // The creator ctor is resposible for setting all defaults
  @JsonCreator
  public XConfig(@JsonProperty("i") final Integer i) {
    this.i = Objects.requireNonNullElse(i, 99);
  }

  public int getI() {
    return i;
  }
  // + equals(), hashcode(), toString()
}

[at055612]

Fixed in > beta.166