So I still have not fully replaced our home grown config with avaje-config because of one feature that I can't decide whether to just work around or have it implemented in avaje-config.

What we have in our system that Avaje does not is we have a

• parser config extension just like Avaje generally based on the file name resource path extension.
• a filter properties extension - not needed really
• loading flags which I talked about - not needed really
• URI schema based custom loading - used a lot!

Basically allow custom loading of resources using URIs. This may already be built with the resource loading SPI but I don't think so.

What I mean by that is we do things like using load.properties as an example:

load.properties=classpath:/somepath.properties env:///MY_PROJECT_PREFIX_DATABASE_/DATABASE_/ gcloud.meta:///

I think the classpath one is obvious and builtin but the env one is builtin for us but I would implement as an extension.

What the environment URI one does is find all environment variables starting with MY_PROJECT_PREFIX_DATABASE_ and replace that starting with DATABASE_. (it does occur to me that perhaps my real use case need is something that just transforms key names but let us just work through this more abstract feature).

Basically internally we have a Map of URI schema to Config loader which is SPI discovered.

// ignore names... you know the bikeshed avoidance drill

interface URILoadingConfigServiceProvider extends ConfigExtension {
  String getSchema();
  Config load(URI uri); // I don't know the exact avaje-config types but you get the idea.
}

Obviously no schema found and it does whatever the defaults are. I realize this adds some more bloat but I think it is not that bad given we have now consolidated service loading to a single call (thank you @SentryMan ).