Empty property in application.properties throw exception by injecting with @ConfigProperty eaven with defaultValue

[waldimiro]

1. Add an empty property in application.properties
   my.empty.property=

2. Inject property
   @Inject @ConfigProperty(name = "my.empty.property") protected String myProperty = null;

3. Exception
   javax.enterprise.inject.spi.DeploymentException: No config value of type [java.lang.String] exists for: my.empty.property

[mb010865]

I think this is and should be intended. If you want a possible empty Property you can make myProperty an Optional

[geoand]

I personally think that is should be allowed (and opened #2766) for it. Lets see what others think.

[gsmet]

@dmlloyd what's the status of the discussion in MP Config regarding this one?

[dmlloyd]

Ongoing. I would say that 50%+ of the weekly meetings have been cancelled in the past few months so progress has been slow.

What I'm thinking is that the policy should be that primitives (other than char) would default to 0/false but would still be required like we do for @ConfigItem. Objects should not and would be considered required unless they're explicitly Optional. That means the case in this issue would never be supported without usage of Optional. Otherwise the property would always be initialized to an empty string even if the value was never specified, which makes it impossible to cause the property to be required.

[rsvoboda]

java.util.NoSuchElementException: Required property my.empty.property not found is a bit confusing message.

Can SRye or Quarkus detect that the property is present, but empty ?

[dmlloyd]

There is no functional difference between empty and missing-without-default. Perhaps a better message would be "Value not present for property x".

[rsvoboda]

Perhaps a better message would be "Value not present for property x".

+1

[cpmoore]

Personally I think empty values should be allowed as it may be an intended value.

[dmlloyd]

If you want to allow empty values, use Optional, which works for all types (not just strings or lists).

[pdolezal]

I personally hate this behavior. There is IMO a big difference between an absent property and a string property with an empty string as its value. Optional is supposed to indicate possibly absent value, i.e., something which would be null otherwise. An empty string is not absent, it is just an empty string. What frustrated me even more was the moment when I specified @ConfigProperty(name = "foo", defaultValue = "") with no success.

Besides… although I understand that using Optional as the silver bullet here is appealing, I don't like it for other reasons as well. I think that Mark Stuart explained that quite clearly: Optional is intended for return types, using it elsewhere smells.

[dmlloyd]

It's the best we can do within the limits of the Microprofile-based configuration framework. Within that framework, an empty value is used to delete a lower-priority configuration value. It's a tradeoff: either there's no good way to represent a present-but-empty string (like today), or there's no good way to explicitly delete a value. The former problem mostly affects extension developers and configuration consumers, whereas the latter problem mostly affects people writing and reading configurations. In the end, the latter group was considered to be more important.

That said, in retrospect, I think we should not have based our configuration system on Microprofile Config. That was a decision I made, but in hindsight I think it was a bad one. Had we based configuration on a more capable structured format, we probably wouldn't have had to make this particular tradeoff at all, while likely still being able to support users of Microprofile Config at an API level.

In the future maybe we'll get a chance to revisit this design.

[sven-geisenhainer]

Using Optional along with @ConfigProperty in a JAX-RS provider gives a warning:

Directly injecting a @ConfigProperty into a JAX-RS provider may lead to unexpected results. To ensure proper results, please change the type of the field to javax.enterprise.inject.Instance<java.util.Optional<java.lang.String>>.

But Instance<Optional<String>> is not an option as it would throw the DeploymentException again.