Runtime configuration vs multiple built images

[meridsa]

We have a situation where we have a kotlin quarkus application with a build-property that configures which data fetching implementation (bean) to use. We have an internal database for mocking data and an external api for "real" data. Right now we are creating the pipelines to create deployable images for this service and hitting the runtime-config issue head on. Ideally we want:

• 1 image that can be deployed in shared-dev, test, qa, staging and prod environments with different configurations
• constructor injection in kotlin
• ability to select implementation at runtime

What does the quarkus philosophy suggest here? Using the LookupIfProperty and programmatic injection seems to fly in the face of quarkus and if you are forced to use it maybe you should consider another framework?

The possible solutions I see using quarkus are:

• runtime bean selection and programmatic injection
• 1 image per build config: service:<tag> & service:mock-<tag>
• 1 image that builds app at container startup with the build config we want

What is the quarkus way of doing it? How can we achieve this in a way which aligned with the quarkus philosophy?

[quarkus-bot[bot]]

/cc @evanchooly (kotlin), @geoand (kotlin)

[maxandersen]

Is the buildtime property a config property in your own extension or how ?

[meridsa]

Configuration property for now. Not opposed to doing it another way.

This issue #20824 discusses the same problem, where the desire for runtime selection ended in @LookupIfProperty. Was there an original plan for this type of issue where different environments need different implementations?

[maxandersen]

The simplest is to produce different builds.

If you really need it you make it a runtime selection dynamic but you will then have the same issues as other frameworks and have overhead for including things you don't use.

For example initially hibernate only supported one datasource. We changed that to allow multiple but in a way that you only pay for exactly what you include.

[geoand]

Using the LookupIfProperty and programmatic injection seems to fly in the face of quarkus and if you are forced to use it maybe you should consider another framework?

This statement is just not correct. @LookupIfProperty is practical choice that is useful for some cases, not useful for most.