Property keys defined at methods overridden by sub-interface not mapped by PropertiesManager

[h-arlt]

We make excessive usage of Owner configuration interfaces (would not do if it wouldn't be such a great library 🙌 ) that all share the same design pattern.

Configuration that is common for a certain functionality is defined in a configuration interface BaseConfig whereas concrete implementations of this functionality use their own configuration interfaces that extend BaseConfig and override methods as necessary such that BaseConfig represents the application default settings that may be overwritten by concrete settings, all using their own property keys and default values.

For example, consider the following configuration interfaces:

interface BaseConfig extends Accessible {
  /// ...
  @Key("feature.default.setting")
  @DefaultValue("-1")
  public long getSetting();

  // ...
}

interface ConcreteFeatureConfig extends BaseConfig {
  // ...
  @Key("feature.concreate.setting")
  @DefaultValue("42")
  @Override
  public long getSetting();

  // ...
}

When we now invoke Accessible#getProperty on an instane of such a concrete configuration interface, we'll get null for all property keys defined at methods overriden by the sub-interface although the overall set of property keys do not overlap and all having their own default value.
This is somewhat unexpected and may become an issue for other users too. I'd rather expect that PropertiesManager keeps track of all properties mapped by a configuration interface, including those that are defined at overriden methods in some super interface, since an override is not a replacement but an overlay.

Could you pleaes clarify whether the observed behavior is per intention and/or our design pattern fits into Owner's concepts .

Thanks in advance and for your efforts 👍