Setting quarkus.http.cors.origins in application.yml

[rinmalavi]

When setting properties

quarkus:
  http:
    cors: true
    "cors.origins": '*'

I would expect "quarkus.http.cors.origins" to be set to "*"

However

WARN  [io.qua.config] (Quarkus Main Thread) Unrecognized configuration key "quarkus.http."cors.origins"" was provided; it will be ignored; verify that the dependency extension for this configuration is set or you did not make a typo

Steps to reproduce the behavior:

1. set in application.yaml (use quarkus-config-yaml)

   quarkus:
   http:
   cors: true
   "cors.origins": '*'

2. watch for output in application logs

quarkus:1.8.1

you can however set quarkus.http.cors.origins in yml.

[sberyozkin]

@rinmalavi should it be just origins ?

[rinmalavi]

Well it works with quarkus.http.cors.origins in .yml as well as .properties
Not sure i undrestood "just origins"?
https://quarkus.io/guides/http-reference#cors-filter

[sberyozkin]

@rinmalavi Oh I see what is the probllem, .cors is overloaded (used to enable and also acts as a segment key)

May be we should have quarkus.http.cors.enabled=true...

CC @gsmet @stuartwdouglas

[gastaldi]

You need to do:

quarkus:
  http:
    cors:
      ~: true

See https://quarkus.io/guides/config#configuration-key-conflicts for more details.

Closing now

[sberyozkin]

@gastaldi super :-)

[micheljung]

If this was documented, it's not anymore

[gastaldi]

Looks like it was moved to https://quarkus.io/guides/config-reference#configuration-key-conflicts

[sylvainpolletvillard]

Moved again to https://quarkus.io/guides/config-yaml#configuration-key-conflicts

[tsprlng]

This is quite a frustrating "solution" as for almost all applications that accept YAML configuration, you can simply generate JSON (as a strict and easily canonicalized subset of YAML, to avoid most of YAML's nightmarish complexity). However, null as a key is not allowed in JSON (only strings can be keys), making Quarkus a quite difficult special case.

If only it was quarkus.http.cors.enabled, life would be easy.

It feels to me like if YAML support is supposed to be a first-class feature, it would be better to use strictly hierarchical keys so that no special hacks are required.

(The ~ keyword may be "fun" but definitely seems like a hack -- while null keys are technically allowed in YAML, it immediately rings quite severe alarm bells when any kind of type-safe integration is used, for example.)

(Raised as issue #34292)