A little SOS from quarkus-artemis-core / quarkus-artemis-jms

[Marco Bungart]

So... I fucked up in quarkus-artemis-core / quarkus-artemis-jms. I tried
to outsmart quarkus. I needed to access the runtime configuration at
compile time in order to see the configuration keys present. For this, I
took the RuntimeConfigurations [1] (ConfigPhase.RUN_TIME)and extended it
with a ShadowRuntimeConfigurations [2]
(ConfigPhase.BUILD_AND_RUN_TIME_FIXED). Problem now is that if we do
something like:

    quarkus.artemis.url=${ARTEMIS_URL:tcp://dummy:61616}

in application.properties, this value gets fixed at build time and is
not overridable at runtime.

On the other hand

    quarkus.artemis.url=${ARTEMIS_URL}

works just fine.

Long story short: I released a pretty broken version (on friday, so no
way to un-release it). Can we do something on the quarkus-end to get
what I need (access certain keys of the runtime configuration at
build-time), or should we revert all changes in a new version?

[1]:
https://github.com/quarkiverse/quarkus-artemis/blob/main/core/runtime/src/main/java/io/quarkus/artemis/core/runtime/ArtemisRuntimeConfigs.java
[2]:
https://github.com/quarkiverse/quarkus-artemis/blob/main/core/runtime/src/main/java/io/quarkus/artemis/core/runtime/ShadowRunTimeConfigs.java

[Guillaume Smet]

Hey Marko,

First I'm not sure really we want to keep the behavior you were using alive. That would be for Roberto to decide.

I think we have a need for the structure to be known when we have multiple datasources/queues... but for now we don't really have a solution.

Probably something we need to think about because it has come up a lot.

Secondly, I fail to see how releasing a new Quarkus would be simpler than releasing a new version of your extension :).

I'm certainly not excited about changing something related to that in either 2.13 or 2.14. So even if we found a solution, that would probably be 2.15 material.

I know it's not really helping you but I will let Roberto comment on the config side.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/72167fc1-cbd6-131f-ef17-184153ac77dc%40googlemail.com.

[Roberto Cortez]

Hi,

Let me look into the extension and check what is going on.

In the meanwhile, let me add some considerations:

What is the use case to access runtime configuration keys during build time? The runtime configuration may have a completely different set of keys. While keys mapped on the Runtime ConfigRoots are known as runtime candidates (and we may get a list of that), some type mappings like Maps that contain dynamic keys may only be present at Runtime. Same thing for indexed properties and Collections (but I believe we are not using these on ConfigRoots). 

There is no reliable way to get all the runtime keys during build time because config sources are different (we distinguish between the build and runtime system properties and environment variables). The application may also set runtime-only sources, like database, consul, vault, etc., which can provide configuration keys that are only visible during runtime.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_2MGTMQqdSA1b-oR6Q6Sg8LH%2B%2BCUd8WVTyK0Mf%2BEftpQ%40mail.gmail.com.

[Guillaume Smet]

We had a few use cases, mostly to have information about the structure of the config when dealing with multiple named entries (for instance, multiple datasources).

We work around it a few times because by having at least one mandatory build time property around but that is not always the case.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/182CAE2D-BE7E-4032-9CB3-72B30BD929D6%40yahoo.com.

[Roberto Cortez]

From my understanding, the use case is to retrieve the names (like datasource names, connections names, etc).

This falls precisely in the category of dynamic properties, which may not be visible during build time (and we cannot infer the keys from the ConfigRoot, because part of the key name is unknown). I don’t think we have any other option than to split the configuration between build time / runtime to get the name.

If all properties are runtime only, and the user only sets them up in a Vault Config Source (a common use case), there is no way for us to know about these keys during the build. 

[Marco Bungart]

Hey all and thanks for the responses.

@Guillaume I never intended for the quarkus platform to make a new release =) I just needed some help.

@Roberto we already had the discussion. It is exactly the use case that Guillaume described. Try to implement datasources without the "db-kind" field, which is always present at compile-time.

I think that it is sensible to assume users won't create new configurations at run time; the configurations will be present in some form or another at compile-time, but not compile-time fixed. I opened a reature-request [1] a while back, which got closed as "not planned" and Roberto cited a discussion we had in zulip, in which I explained my (quite dirty) work-around. So I am pro keeping this behaviour alive.

As I said in a previous mail [2], one possibility is to group everything under a common subkey, e.g. "quarkus.jms" and introduce a "connection-type" (or similar), in-line with "datasources".

So for now, we have a workaround by binding properties twice (once in a RUN_TIME config, once in a BUILD_TIME config). This will lead to a warning at application startup since we rebind a build time property, but it works as intended.

[1]: https://github.com/quarkusio/quarkus/issues/28415

[2]: https://groups.google.com/g/quarkus-dev/c/thdTCj-XNUU/m/yrWTg2gPBAAJ

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/EEDF175E-EA68-46C9-AAF1-02B7E5E25CCF%40yahoo.com.

[Roberto Cortez]

Unfortunately, you cannot assume that users will have their configuration available during the build. Again, it is very common for users to rely on Vault to set such configurations, especially those with passwords. Vault is only available during runtime, so you cannot reliable determine the available keys during build.

I’m happy to figure out a way around this. Still, I don’t see any other option than requiring a build-time property configuration that can state the expected names somehow so they can be reliably picked during runtime.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/d6d669f3-7b58-ab9e-d348-49aeabc0c427%40googlemail.com.
<OpenPGP_0x1D62FE7F6FECFBC5.asc>

[Max Rydahl Andersen]

Having to state db-kind or similar is the current solution for this. It’s a small price imo. 

Consistency and no unnecessary warnings is a virtue we should keep following.

Any reason why not to do the same thing here?

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/d6d669f3-7b58-ab9e-d348-49aeabc0c427%40googlemail.com.

--

/max

https://about.me/maxandersen