Unable to update to smallrye config 3 optional nested interface issue

[manofthepeace]

Hi,
I tried to upgrade to quarkus 3, but I did hit a blocker with the config mapping when using optional and nested interfaces.

Reproducer: https://github.com/manofthepeace/configmapping-issue-q3

if you run with quarkus:dev the app with fail with the following;

Caused by: java.util.NoSuchElementException: SRCFG00014: The config property my.test3.valid is required but it could not be found in any config source

If you change the quarkus version from 3.0.4 to 2.16.7 in the pom it works as expected.

Thanks for the help.

[manofthepeace]

After more testing I did not find a really viable workaround. If I set the sub interface to also be optional, it then complains with another one, and all its properties. It goes back a little to this I find; #845.

So In my real case I have one Optional to simulate the optional configmappring and let an application start, but now all my nested interface of that Optional (I have 5) need to be optional as well, which makes the code a bit so so by doing the extra get() on the Optional, which in fact they arent't optional, its a all or nothing either none of the Optional are there, or they all are. By putting them all optional in the nested Optional it makes them all optional which is actually not ok.

[radcortez]

I'll have a look.

[manofthepeace]

Thank you. For information, in my app I have another ConfigMapping that uses the same pattern meaning one @WithParentName Optional<Property> property();

where Property contains some props + one non optional sub interface, and it all works fine. I've been trying to find what triggers the issue but was unable to find the exact combination. I think it may be with the collection, as my other configmapping that works dos not have a nested list like the other does.

[radcortez]

The trigger is the @WithDefault.

Now, a @WithDefault in a nested Optional triggers the build of the Config tree. An Optional and a default are opposing concepts. With the previous behavior, retrieving the default value was only possible if another property of the tree was specified.

[manofthepeace]

Hum I see, that is interesting. What is your take on that? After reading your previous comment a couple times I think it does make sense, with WithDefault, it actually puts a value, which is then not a all or nothing anymore. So it was sort of a bug previously in a way..

I think when the fix with the dotted WithName will be in I will be able to use the default outside of the optional and that would work right? If so I think this should be closed then. I moved to multiple sub interface because the WIthName with dotted names did not work properly.

[radcortez]

Hum I see, that is interesting. What is your take on that? After reading your previous comment a couple times I think it does make sense, with WithDefault, it actually puts a value, which is then not a all or nothing anymore. So it was sort of a bug previously in a way..

Correct.

I think when the fix with the dotted WithName will be in I will be able to use the default outside of the optional and that would work right? If so I think this should be closed then. I moved to multiple sub interface because the WIthName with dotted names did not work properly.

Yes. Sorry for taking longer to release. We are trying to nail down some additional features to Maps.

[manofthepeace]

No worries at all! Thanks for your time today (and all other days).

[radcortez]

Closing this then :)