Improve ConfigProperty lookup

Description

As a:

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

…I need to be able to:

use @Inject @ConfigProperty("property.name") instead of having to put a name attribute there @Inject @ConfigProperty(name="property.name")

…which enables me to: simply my lookup.

[Emily-Jiang]

@Emily-Jiang - in both options you propose, you use:

@Inject @ConfigProperty(name="customer.name", value="Bob") String name; 

This is very confusing, as you use value once for default value, and once for property name. You still have defaultValue option on the ConfigProperty.

This is confusing and neither of the options is good

ah. Sorry for the confusion. It was a typo. I meant @Inject @ConfigProperty(name="customer.name", defaultValue="Bob") String name; As mentioned in the very first comment, if someone specifies both name and value, this should resolve to an error. The value attribute in the annotations has special meanings. Putting value in this annotation means the name of the property might not be a good fit, which is even true if this property has no other attributes. I appreciate the suggestions etc. After this conversation, I think the current usage is the best approach among others and less confusion. As an end user, I’m happy to type in name= to make my code readable. Besides, IDE will help me anyway. With this, I’m going to close my issue.

[ljnelson]

I’d like to make sure I understand this absolutely clearly.

You are proposing that:

1. three elements will exist on the ConfigProperty annotation: name, value and defaultValue
2. All will be declared as not required, so that an annotation of, simply, @ConfigProperty is at least syntactically legal (if not semantically legal)
3. name and value will represent exactly the same thing even though they designate completely different concepts
4. All usages of this new ConfigProperty annotation must be scanned and validated to ensure that incompatible values are not specified together, and that at least one of either name or value is specified

Does that correctly represent what you are proposing?

This will almost certainly be immensely confusing to end users and consequently I object to it.

Perhaps a replacement annotation is called for instead (perhaps without default-value semantics as well, given how haphazardly #446 (and #531 and #532 and #533) was addressed, and how thorny default values are in general, and how difficult they are, therefore, to encode in the primary qualifier annotation, as many issues have borne out)?

Simpler, clearer replacement possibilities might include:

• ConfigKey("foo")
• ConfigKeyNamed("foo")
• Value("foo")
• ValueNamed("foo")
• Setting("foo")
• SettingNamed("foo")