Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate interface based Configuration #12

Open
struberg opened this issue Oct 31, 2017 · 10 comments
Open

Evaluate interface based Configuration #12

struberg opened this issue Oct 31, 2017 · 10 comments
Labels

Comments

@struberg
Copy link
Contributor

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?

@jmesnil
Copy link
Contributor

jmesnil commented Nov 16, 2017

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

@struberg
Copy link
Contributor Author

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.

@sdaschner
Copy link
Contributor

sdaschner commented Nov 23, 2017

+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.

@lilian-benoit
Copy link

+1

@Emily-Jiang
Copy link
Member

Emily-Jiang commented Dec 4, 2017

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.

@atsticks
Copy link
Contributor

+1 Apache Tamaya also supports this feature.

@rmannibucau
Copy link

+10000, only blocker for me to use mp-config

@tomas-langer
Copy link
Contributor

+1

@struberg
Copy link
Contributor Author

Is related to #58

sdaschner added a commit to sdaschner/ConfigJSR that referenced this issue Aug 17, 2018
sdaschner added a commit to sdaschner/ConfigJSR that referenced this issue Aug 23, 2018
@sdaschner
Copy link
Contributor

Updated my PR #85 based on yesterday's (2019-05-02) meeting. @struberg @Emily-Jiang please review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants