Fallback configuration property name

[radcortez]

Configuration property names change and this requires you to update all of your Config Sources to make sure you have the right name and find the right configuration.

Also, on the implementations side, there are vendor based configurations that may move to the API spec level, effectively changing the configuration namespace, but serving the same purpose.

For instance in SmallRye JWT, the configurations smallrye.jwt.token.cookie and smallrye.jwt.token.header are going to be part of MP JWT in the namespace mp.jwt.token.cookie and mp.jwt.token.header. Now, in the implementation side, we need to support both.

It could be interesting to support some sort of fallback, that allows you to relocate the namespace of the configuration and falling back to other known names for retro compatibility purposes.

[radcortez]

Quick idea:
This could be implemented by a combination of a ConfigSource with low priority and Property Expansion.

[dmlloyd]

Just fyi, but I proposed something like this for Quarkus and it was rejected at the time.

As for implementation, this seems like a natural use for interceptors.

[radcortez]

I think the use case has some merit. At least, I've already came across with it a few times and now again. In SmallRye JWT we are moving some configurations to the Spec, so we are going to need to support the smallrye namespace and now the spec namespace.

The interesting thing is that I don't think we need much work to do this. With the Property Expansions, users can easily implement this with a lower priority ConfigSource. We could give them the ConfigSource and a specific file to contain the relocations / fallback, but it would work as any config source.

For instance:
smallrye.jwt.token.header relocates to mp.jwt.token.header

RelocationConfigSource just a file called relocation-config.properties with priority 1:

mp.jwt.token.header=${smallrye.jwt.token.header}

So, when you search for mp.jwt.token.header you evaluate all sources, find nothing until you get to the final one which expands to the relocated name and evaluates the entire ConfigSource chain to find the value if you are still using the old config.

[dmlloyd]

Sure, a config source would work, but it does cause many expression objects to be created and expanded. An interceptor is more concise because you can spell out exactly what you want, e.g. if (name.startsWith("mp.jwt.")) { try "mp.jwt.", then try "smallrye.jwt"; } else { just proceed }

[radcortez]

Yes.

This example is just a simple case. But probably not every case is going to be a direct check like and I think it would be interesting to give a configuration based rule approach so you don't have to implement the interceptor yourself (or just fallback to it for tricky cases).

We can implement the file idea anyway with the interceptor, so you don't have to code all the rules and just have a simple:

mp.jwt.specific=smallrye.another.x
mp.jwt.*=smallrye.jwt.*
...

[radcortez]

BTW, how were you intending to implement this is Quarkus?

[dmlloyd]

I would have used a config source wrapper, most likely. But we have interceptors now, which are better.