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

Allow empty configuration values for String injection points #2766

Closed
wants to merge 1 commit into from

Conversation

geoand
Copy link
Contributor

@geoand geoand commented Jun 9, 2019

Fixes #2765

@@ -38,6 +38,9 @@
@Inject
Config config;

@ConfigProperty(name = "greeting.empty")
String empty;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good to also test the Optional case to be sure it gets an Optional<String> with an empty String

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, this is not correct according to the comment made above (getOptionalValue returns an empty Optional when the string value is an empty string this should not be considered an error).
I guess an Optional with an empty string must be injected in this case, not an empty optional.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually we don't really control that part, the value comes from MP config (we just create the config source), so I'm not really sure what we should do.
Any ideas?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cescoffier the TCK passes, so I think this is safe. WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cescoffier ping.

@kenfinnigan
Copy link
Member

Would be curious to know if this changes with updating SmallRye Config.

I vaguely recall some changes around empty strings but not certain. Do you recall @dmlloyd?

@dmlloyd
Copy link
Member

dmlloyd commented Jun 13, 2019

There is currently a disagreement in the MP Config community about handling of empty values. The discussion is primarily here: eclipse/microprofile-config#407

If you agree with my proposal, then the correct behavior is to treat empty and missing as identical. In this case, if the intent of injection plain fields is to fail on a missing value, then it also would mean failing on an empty value.

@geoand
Copy link
Contributor Author

geoand commented Jun 13, 2019

OK, so I guess for the moment we shouldn't change anything here until we have a resolution

@geoand geoand added the triage/on-ice Frozen until external concerns are resolved label Jun 13, 2019
@starksm64
Copy link
Contributor

starksm64 commented Jun 14, 2019 via email

@starksm64
Copy link
Contributor

starksm64 commented Jun 14, 2019 via email

@dmlloyd
Copy link
Member

dmlloyd commented Jun 14, 2019

Unfortunately I woke up too late to make the call, which I guess must have been at 5am my time. The conclusion is far from satisfactory though: it actually adds more confusing behavior.

@starksm64
Copy link
Contributor

What is the best way to try to drive this to the conclusion we want? Does the updated tck/src/main/java/org/eclipse/microprofile/config/tck/EmptyValuesTest.java enumerate every possible variation of the empty value scenario so there is one place to see the impact of how this is handled?

@FroMage
Copy link
Member

FroMage commented Jun 19, 2019

@kenfinnigan should we ask our guys from smallrye-config to participate in this discussion?

@kenfinnigan
Copy link
Member

@dmlloyd and @jmesnil have been duking it out in MP Config and SR Config for a while.

@FroMage
Copy link
Member

FroMage commented Jun 19, 2019

@kenfinnigan who's winning?

@kenfinnigan
Copy link
Member

MP Config I think at present

@dmlloyd
Copy link
Member

dmlloyd commented Jun 19, 2019

The crows

@FroMage
Copy link
Member

FroMage commented Jun 19, 2019

OK, I pitched in. Couldn't even make it worse given how stuck this is.

@dmlloyd
Copy link
Member

dmlloyd commented Jul 10, 2019

We've been slowly making progress on discussions around this issue on the spec calls, but it's still unresolved.

@geoand
Copy link
Contributor Author

geoand commented Jul 10, 2019

Thanks for the update @dmlloyd !

@geoand geoand closed this Sep 14, 2019
@gsmet gsmet added the triage/invalid This doesn't seem right label Sep 18, 2019
@vsevel
Copy link
Contributor

vsevel commented Feb 27, 2024

We've been slowly making progress on discussions around this issue on the spec calls, but it's still unresolved.

do you have an update @dmlloyd ?

@dmlloyd
Copy link
Member

dmlloyd commented Feb 27, 2024

The existing behavior stands. If an empty value is allowed, the property must be of type Optional<String> (and use Optional.orElse("") to extract the empty string value); if it is not allowed, then the type should be String, and an empty value will give a validation error (required property is missing).

If we mapped empty values to empty string, then we would have no way to declare that a String-typed property is required (i.e. must be non-empty). This also would break the existing validation behavior for existing uses where an empty string is not a valid value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/invalid This doesn't seem right triage/on-ice Frozen until external concerns are resolved
Projects
None yet
8 participants