quarkus: CORSConfig is not representable as YAML
As seen during #4525 development, CORSConfig cannot be represented as YAML because we’d need the quarkus.http.cors key to be both the key of a key/value pair and the key of a dictionary, which is not possible.
A properties-based CORS filter configuration currently looks like this:
quarkus.http.cors=true
quarkus.http.cors.origins=http://foo.com,http://www.bar.io
quarkus.http.cors.methods=GET,PUT,POST
quarkus.http.cors.headers=X-Custom
quarkus.http.cors.exposed-headers=Content-Disposition
quarkus.http.cors.access-control-max-age=24H
We only need to change the quarkus.http.cors=true property to quarkus.http.cors.enabled=true to make it convertible to YAML.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 25 (24 by maintainers)
Commits related to this issue
- Introduce YAML configuration extension Fixes #3904, fixes #4568 — committed to dmlloyd/quarkus by dmlloyd 5 years ago
- Introduce YAML configuration extension Fixes #3904, fixes #4568 — committed to dmlloyd/quarkus by dmlloyd 5 years ago
- Introduce YAML configuration extension Fixes #3904, fixes #4568 — committed to dmlloyd/quarkus by dmlloyd 5 years ago
- Introduce YAML configuration extension Fixes #3904, fixes #4568 — committed to dmlloyd/quarkus by dmlloyd 5 years ago
- Introduce YAML configuration extension Fixes #3904, fixes #4568 — committed to mmusgrov/quarkus by dmlloyd 5 years ago
Here’s the complete list of config keys that are currently not representable as YAML, based on the
ALL CONFIGURATION OPTIONSdoc page (I’m glad it existed to do this check!):^
quarkus.hibernate-orm.database.generationcould be replaced withquarkus.hibernate-orm.database.generation.autoto match the original Hibernate property. @gsmet WDYT?^
quarkus.hibernate-orm.dialectcould be replaced withquarkus.hibernate-orm.dialect.namebut it differs from the original Hibernate property. @gsmet WDYT?^
quarkus.http.corswill becomequarkus.http.cors.enabled^
quarkus.log.console.asynccould be replaced withquarkus.log.console.async.enabled^
quarkus.log.file.asynccould be replaced withquarkus.log.file.async.enabled^
quarkus.log.syslog.asynccould be replaced withquarkus.log.syslog.async.enabledI also noticed several configuration keys being used by
quarkus-agroal,quarkus-reactive-mysql-clientandquarkus-reactive-pg-client. I’m not sure that’s an issue though, but I’d like your opinion about it:I’ll see if that kind of issue can be detected at build time, but I’m not sure it’ll be easy. Half of these cases were related to the use of
@ConfigItem(name = ConfigItem.PARENT)and the other half was the consequence of hardcoded config keys names using@ConfigItem(name = "foo").I like the idea. I guess this would have to be done in the
YamlConfigSourcethat is currently being donated frommicrprofile-extensionstosmallrye-config, as discussed in #4525.I’ll give empty YAML keys a try with #4525 as it is currently using the same YAML parser (snakeyaml) than the future
smallrye-configversion. It might already support empty keys.Right. Rather than upend the entire configuration system to accommodate YAML, maybe we can hack YAML a bit to accommodate the config system. So if I have
foo.barandfoo.bar.baz, then in the YAML maybe in addition to looking for abarinside of afoo, we should look for a*within abarwithin afoo.Ah well empty keys are probably the exact right thing to use in this case since it’s in the spec, presumably for this exact purpose.
This would be solved as well by allowing an empty key within
dialectto be used fordialect.Great, thanks @gwenneg
We have the test-extension with possible configuration values - https://github.com/quarkusio/quarkus/tree/master/core/test-extension/runtime/src/main/java/io/quarkus/extest/runtime/config with a rather large test suites here - https://github.com/quarkusio/quarkus/tree/master/core/test-extension/deployment/src/test/java/io/quarkus/extest
not sure if we must have the same coverage with a
yamlfile, but the extension is handy when you want to test various things, config among others 😃HTH.
Yes, that’s a good point @machi1990.
I was planning on checking all config classes while fixing
CORSConfig😃I think the issue is related to having something like: quarkus.extension.foo = … quarkus.extension.foo.bar = …
On Tue, Oct 15, 2019 at 6:20 PM Manyanda Chitimbo notifications@github.com wrote: