Problem

Today, Dist.X requires users to run the config command in order to update the server configuration. While this is an important aspect in order to provide an optimal runtime, it often brings some confusion when configuration the server as well as common mistakes when changing specific configuration properties that only take effect when the server is re-augmented.

We all should agree that the introduction of this behavior is not very natural for most people and often causes confusion on whether or not the config command should run as well as error-prone in case you forget to run the command when changing static properties.

That said, we should consider improving user and developer experience for non-production usages such as when trying out Keycloak capabilities or when developing custom extensions.

Proposal

Instead of forcing users to run the config command whenever static property changes, the runtime could calculate whether the server should be re-augmented and run the command transparently to the user.

Considering the scope here is not production, we should not care much about the impact of this step in the startup time neither on memory footprint. For production deployment, users should still consider running the config command prior to starting the server or when building container images for optimal runtime.

Ideally, re-augmentation should happen within the same process created to start the server. In this case, the calculation should be simple and fast enough and its impact on the startup time and memory footprint should be minimal.

If not possible to run using a single process, we should consider updating the kc.sh script to create two sequential processes: one to calculate and decide whether re-augmentation should happen and run it and another to actually start the server.

No matter what the situation, the dynamic re-augmentation should only run when starting the server in dev mode. In other words, when running the start-dev command. The reason for that is to avoid any (even if minimal) impact on the server startup time in production.

Implementation

A working branch was created to test the different approaches, starting with automatic re-augmentation within a single process based on Quarkus Classloading internals. To try it out, see:

• [KEYCLOAK-19306] - Automatic re-augmentation #8450

References

• Configuring Keycloak