CC @shawkins

Unreported flaky test detected

If the below 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.adapter.servlet.OfflineServletsAdapterTest#testServlet

Keycloak CI - Base IT (2)

java.lang.AssertionError: 

Expected: not null
     but: was null
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
...

Report flaky test

@shawkins This PR should be ready for review. I'd be happy if you'd have a chance to look at it.

I still need to finish some additional things:

• Add description to this PR with the provided functionality (and possibly show some outputs)
• Add/fix some more tests
• When the distro is not augmented, the validation of the disabled runtime options is made after the reaugmentation (f.e. when start without --optimized is used; for build works as expected)

@shawkins Thanks for the review! :))

If I understand correctly this will handle enablement as long as it's conditional on properties that are set prior to parsing - which most are. But anything that is set as a side effect of the command, such as the StartDev forceDevProfile that won't be known. Is that correct?

It should handle such situations, but I'll write a test for it and double-check it.

I haven't had a chance to run this, but was wondering will this make both help and help-all conditional? That is if you have something like --log=file --help-all will you see any of the file or gelf options?

Only --help is conditional. If you specify --help-all, all options are printed, even disabled ones with the message when the option is available to the user.

Rebased and added test execution order for the OptionsDistTest. It's not possible to execute start-dev, and then start without explicit build execution. It's the current behavior in Keycloak. We might discuss some improvements around it, but it's out of the scope of this PR.

It was a bit hard to review as it adds a lot of additional complexity.

@vmuzikar Yep, I'm aware of it. But the code should be cleaner now and also catch some minor issues.

Do we have any perf benchmark comparison? I know there's a slight impact on the startup performance. Is there any hit on runtime too?

There should not be any performance degradation even for the startup; I resolved that one I mentioned previously. I made only a small perf analysis and nothing that could impact performance :)) The only thing that has changed is that the initialization of Profile(quite resource-consuming) is done earlier.

I can double-check it.

@shawkins Could you please review the last commit? Thanks!

Created follow-up tasks and addressed in the parent issue (#13113):

• Move import/export validation to the Property Mappers #27025
• Consider mapFrom attribute for disabling Property Mappers #27026

Rebased and resolved conflicts.

@shawkins @vmuzikar Can you please check it again? Thanks!

One minor after thought is at what point could or should we be able to clear some of the static state - how big of a footprint does the parsed command have?

@shawkins Sorry, it seems I've missed your comment.

I assume you mean the static object Environment.parsedCommand. AFAIK pointers/references of static objects are stored in Metaspace, which directs to objects stored in the heap. After getting the heap dump, I noticed that the retained memory for the Environment.parsedCommand is ~28.5kB with the inner CommandSpec objects.

However, as the GC was executed before the heap dump, all other CommandLine#CommandSpecs were still present, so they're not garbage collected either. That means the parent CommandSpec still references the child specs - I assume it's stored even for the reflection capabilities of Picocli. Thus, IMHO, the footprint does not really matter in this case as there should not be any major differences due to the shared references.

@vmuzikar May I ask you for a next round of review? Thanks

@shawkins @radcortez @vmuzikar Thanks for the reviews! :)