ConfigJSR Evaluate interface based Configuration

In Apache DeltaSpike you can define an interface which gets automatically provided as accessor for configured values

http://deltaspike.apache.org/documentation/configuration.html#_interface_based_configuration

It's basically the approach first seen in Owner. You simply write an interface and the getters automatically get implemented to look up a configured value.

Are we interested in providing such a mechanism in JSR-382?

Oct 31 '17 17:10 struberg

What's the advantage compared to having a simple class that injects @ConfigProperty in its fields?

Nov 16 '17 10:11 jmesnil

There are a few.

You can define a cacheFor=xxx time on the whole class, even for native types like int.
You can define a prefix org.acme.some.project for the whole class and derive the config keys from the interface methods.
you have it in one place vs injecting a certain config into every place where you need that value.

But of course this feature is a nice add-on on top of the core mechanism. One can easily build it for oneself as well.

Nov 16 '17 12:11 struberg

+1 Yes, very helpful for configuration scenarios with complex configuration or cases where config values are splattered across the whole app. Keeps the various configuration injection points DRY.

Nov 23 '17 12:11 sdaschner

+1

Dec 02 '17 13:12 lilian-benoit

There are a few.

You can define a cacheFor=xxx time on the whole class, even for native types like int. You can define a prefix org.acme.some.project for the whole class and derive the config keys from the interface methods. you have it in one place vs injecting a certain config into every place where you need that value.

But of course this feature is a nice add-on on top of the core mechanism. One can easily build it for oneself as well.

What you have listed advantages do not exist as yet. I would say we the next issue we can get in or try to get in is the dynamic handling.