fix: fully sanitizing mappers and changing duplicated log to trace #42959
Conversation
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.webauthn.account.WebAuthnSigningInTest#setUpLinksTestKeycloak CI - WebAuthn IT (firefox) |
dbd5149 to
d4780b5
Compare
| fromOption(ExportOptions.FILE) | ||
| .to("kc.spi-export--single-file--file") | ||
| .paramLabel("file") | ||
| .isEnabled(c -> c instanceof Export) |
There was a problem hiding this comment.
So, when there's some duplication, we'd need to explicitly enable/disable the mapper, right?
Why we should remove the check of the command.getOptionCategories()? It was quite nice approach(idea) on how to eliminate the mapper from "denied" category - so, no explicit check of the command.
Would it be possible to have it checked based on the used optionCategories? And if there are some duplicated mappers in 2 or more categories, require to add some explicit check.
I could imagine even have the default value for the isEnabled the check of the comman categories. So, every mapper with the associated option in the denied category would be disabled.
@shawkins WDYT?
There was a problem hiding this comment.
So, when there's some duplication, we'd need to explicitly enable/disable the mapper, right?
Yes. The import / export property mappers are really a pretty special case. They overlap and are valid only for their respective commands. Honestly I'm not sure we even want someone putting file=... into the keycloak.conf as it's not clear that should represent both the import and export location. We've also talked about having the keycloak.conf more easily scoped per command, but that's an even bigger change.
Why we should remove the check of the command.getOptionCategories()? It was quite nice approach(idea) on how to eliminate the mapper from "denied" category - so, no explicit check of the command.
I would like to further refine the option categories handling in other prs. The problem is that it's not a great abstraction - it is ultimiately about hidding options and it's behavior can be different between build and runtime options.
There was a problem hiding this comment.
Yes. The import / export property mappers are really a pretty special case. They overlap and are valid only for their respective commands. Honestly I'm not sure we even want someone putting file=... into the keycloak.conf as it's not clear that should represent both the import and export location. We've also talked about having the keycloak.conf more easily scoped per command, but that's an even bigger change.
@shawkins In the context of CLI and putting the command with the --file, the scenario is nice as you don't have to specify sth like --import-file, or --export-file. However, yes, totally unusable in the keycloak.conf as having the file= there.
I would like to further refine the option categories handling in other prs. The problem is that it's not a great abstraction - it is ultimiately about hidding options and it's behavior can be different between build and runtime options.
Ok, works to me.
...untime/src/main/java/org/keycloak/quarkus/runtime/configuration/mappers/PropertyMappers.java
Show resolved
Hide resolved
quarkus/tests/integration/src/test/java/org/keycloak/it/cli/dist/StartCommandDistTest.java
Show resolved
Hide resolved
closes: keycloak#38438 Signed-off-by: Steve Hawkins <[email protected]>
Scaled back replacement for #41886 - it turns out that I need these changes first to further refine picocli performance.
closes: #38438