Get Quarkus default buildtime configuration without starting quarkus

[DGuhr]

Hey there,

Dominik from Keycloak team here.

I have a question around the quarkus configuration, but let me explain the context first:

As you perhaps know we have a kinda special quarkus case with keycloak, as we use the mutual jar approach to make the build step transparent to the user. Also, we have an auto-build step that invokes the build through a rule engine, so when quarkus property wrapped by our configuration layer is a build time property, it automatically invokes a new build (on the cost of startup time etc for sure).

All works fine here as long as we have wrapped quarkus properties (see here for our wrappers).

Nevertheless we also have the capability for people who really want to use quarkus raw properties, to use a quarkus.properties file (more on that here )

As of now, all quarkus properties are handled as.build-time properties in keycloak. So far so good, but this leads to some interesting edge cases. Concrete example: We had exactly one request to have SYSLOG logging. To make it short, this wouldn't justify creating and maintaining a wrapper around these quarkus properties, so for this case we pointed to the quarkus.properties.

But SYSLOG is environment dependant (having an external syslog server whose url changes from dev to stage to prod to ...) so the person asked to also be able to use quarkus runtime config as runtime config in keycloak.

This is why I created this PoC today. With these changes in, it works to have quarkus runtime properties also handled as keycloak runtime properties, and quarkus buildtime properties need a build.

So nearly all is fine. Nearly? Yeh, well, remember the --auto-build? In that case, we check against some rules here and this ruleset only knows about our wrapped values, not buildtime values not used/wrapped by us atm, such as e.g. quarkus.hibernate-orm.metrics.enabled=false.

So for auto-build, the ruleset would need to know if a property in the quarkus.properties file is considered buildtime or runtime. At this point, quarkus is not really started from our side, as determining if a build is needed happens as part of our quarkus cli wrapper that starts quarkus only on invoking start or start-dev. So now there's my question if you can think of any way to get the default quarkus config at that point in the lifecycle, so we could check if a property is build- or runtime and invoke a build depending on that?

I am well aware this is kind of against the quarkus mindset, so tbh I expect a "no thats not possible", but wanted to ask before going ahead. In case of doubt this is more of a documentation issue for an edge case on our side, so when people really want to use quarkus raw config they need to rely on quarkus raw behaviour, that is "auto-build does not work with raw quarkus buildtime config". As said, just wanted to ask if I am missing something ;)

[maxandersen]

You can scan for annotations and get a good first guess.

We could also generate a file describing the config which would include what is buildtime vs runtime config.

We kind have parts of it for all guide generation.

So to answer the question - I would generate this per jar and embed it in meta-inf to be able to look it up without starting quarkus. Useful for not just your case but dev time tools such as an IDE.

This is an old idea but I think we should explore it. See #5229 there is also a thread on quarkus-dev on this.

[DGuhr]

Hey Max, thanks for answering first of all.

While implementing this PR on our side I had the thought that it would really be great to have sth along QuarkusApplication.validateConfig(), QuarkusApplication.getCurrentConfig(), QuarkusApplication.isBuildTimeProperty(...) etc. to be able to compare and validate the new property we set.

I think this could also come in handy when e.g. applying configuration from an operator, to see a mismatch before actually applying it to a pod, or when applying new configuration using the command mode, without actually starting the server (as we do).

Atm I kinda manually check for a few "not really but somehow supported" raw build properties (see the additional datasources part and the coirresponding issue for more information on the use-case) on our side for the first iteration, but it would make life much easier when we had a way to check this using quarkus, not manually in our "wrapping layer" in keycloak.

So yes, I also think it's worth exploring. Tbh I haven't worked much with the quarkus codebase yet, but maybe I find some time in the future. Any hints on where to start are appreciated ;)

[radcortez]

https://github.com/quarkusio/quarkus/blob/main/core/deployment/src/main/java/io/quarkus/deployment/configuration/BuildTimeConfigurationReader.java probably contains what you need, but it is not intended to be a public API.

Anyway, have a look and we can probably adjust some pieces and offer a public API to solve this use case.