Update MicroProfile Config to 3.1

[radcortez]

@mkouba I've added some validation code to the ConfigStaticInitCheckInterceptor. This was the only was I could find to be able to validate methods injection points for @Initialized events.

For what I could tell, events get injected on Arc initialize, which will throw the error, meaning that our validation with the Recorder comes too late.

Maybe there is a better way to do this?

[mkouba]

@mkouba I've added some validation code to the ConfigStaticInitCheckInterceptor. This was the only was I could find to be able to validate methods injection points for @Initialized events.

For what I could tell, events get injected on Arc initialize, which will throw the error, meaning that our validation with the Recordes comes too late.

Maybe there is a better way to do this?

Hi @radcortez, which specific events do you have in mind? Could you be more specific pls?

Also note that this validation applies to all @ConfigProperty injection points. Currently we don't fail in static init if there's for example @ConfigProperty String foo injected and the value does not change at runtime. After your change, we would fail.

[radcortez]

Hi @radcortez, which specific events do you have in mind? Could you be more specific pls?

Something like this:

@ApplicationScoped
public class ConfigObserver {
    public void onStartup(@Observes @Initialized(ApplicationScoped.class) final Object event,
            @ConfigProperty(name = "this.property.does.not.exist") final String nonExistentConfigurationPropertyValue) {
    }
}

Also note that this validation applies to all @ConfigProperty injection points. Currently we don't fail in static init if there's for example @ConfigProperty String foo injected and the value does not change at runtime. After your change, we would fail.

It would only fail if there is no value for a non Optional / Instance / Supplier injection point, which would fail anyway in

quarkus/extensions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigRecorder.java

Line 32 in ac4354d

public void validateConfigProperties(Set<ConfigValidationMetadata> properties) {

The issue here is that a regular injection point in an @ApplicationScoped bean is delayed until we execute the recorder, but for events, it would try to inject them without us being able to validate at Arc init.

[mkouba]

Also note that this validation applies to all @ConfigProperty injection points. Currently we don't fail in static init if there's for example @ConfigProperty String foo injected and the value does not change at runtime. After your change, we would fail.

It would only fail if there is no value for a non Optional / Instance / Supplier injection point, which would fail anyway in

If I read the code correctly it's the other way around? For example, if null value and type instance of ConfigValue the log the debug message otherwise throw DeploymentException.

quarkus/extensions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigRecorder.java

Line 32 in ac4354d

public void validateConfigProperties(Set<ConfigValidationMetadata> properties) {

The issue here is that a regular injection point in an @ApplicationScoped bean is delayed until we execute the recorder, but for events, it would try to inject them without us being able to validate at Arc init.

The goal of the ConfigStaticInitCheck is to detect values injected into any injection point (such as a dependency of a @Singleton bean instantiated during STATIC_INIT or an @Observes @Initialized(ApplicationScoped.class) observer) (which is fired during STATIC_INIT, unlike StartupEvent), record the value and compare it with a value produced at runtime. In your example with @ConfigProperty(name = "this.property.does.not.exist"), if no property exists during STATIC_INIT, we record null and then at runtime if the same property is injected and != null then we fail.

[radcortez]

Let me take a step back.

The goal here is that @ConfigProperty injection points that cannot be satisfied by an existent configuration value must fail with a DeploymentException. In the case of the Observer event, we fail with the NoSuchElementException thrown by SmallRye Config because the configuration value cannot be found.

What we did until now is to record the properties to validate in

quarkus/extensions/arc/deployment/src/main/java/io/quarkus/arc/deployment/ConfigBuildStep.java

Lines 195 to 196 in 60c24cb

	void validateConfigValues(ConfigRecorder recorder, List<ConfigPropertyBuildItem> configProperties,
	BeanContainerBuildItem beanContainer, BuildProducer<ReflectiveClassBuildItem> reflectiveClass) {

and then use the recorder

quarkus/extensions/arc/runtime/src/main/java/io/quarkus/arc/runtime/ConfigRecorder.java

Line 32 in ac4354d

public void validateConfigProperties(Set<ConfigValidationMetadata> properties) {

to check for the values and throw the DeploymentException.

In this particular case, with the event and observer, it does not work. I know that the interceptor is not supposed to be used like that, but I couldn't find any other way to validate the injection point at runtime because the injection point for the event calls the producer on Arc.initialize, so before our recorder can execute the validation.

If I read the code correctly it's the other way around? For example, if null value and type instance of ConfigValue the log the debug message otherwise throw DeploymentException.

Yes, ConfigValue is fine, not throwing the DeploymentException because it is a configuration container type (such as Optional, Provider, etc.). The goal is to throw the exception when a mandatory injection point like String cannot be injected.

For these cases, is there a way we can validate the injection point runtime value without using the interceptor?

[mkouba]

The goal here is that @ConfigProperty injection points that cannot be satisfied by an existent configuration value must fail with a DeploymentException. In the case of the Observer event, we fail with the NoSuchElementException thrown by SmallRye Config because the configuration value cannot be found.

Do I understand it correctly that the exception type is the actual problem? Because ConfigProducer methods throw NoSuchElementException but someone expects a DeploymentException?

In this particular case, with the event and observer, it does not work. I know that the interceptor is not supposed to be used like that, but I couldn't find any other way to validate the injection point at runtime because the injection point for the event calls the producer on Arc.initialize, so before our recorder can execute the validation.

I see.

For these cases, is there a way we can validate the injection point runtime value without using the interceptor?

Directly in the io.smallrye.config.inject.ConfigProducer?

[radcortez]

Do I understand it correctly that the exception type is the actual problem? Because ConfigProducer methods throw NoSuchElementException but someone expects a DeploymentException?

Correct.

Directly in the io.smallrye.config.inject.ConfigProducer?

I guess it may work. We validate the values in AfterDeploymentValidation for the regular CDI Extension, so the producer is always going to work. Let me have a look.

[radcortez]

I've ended up following a different approach.

Match the injection points required at static init and have two validation phases, one for static and another for runtime.

[gsmet]

I'd like to better understand our strategy regarding MicroProfile updates. Is this update part of a broader set of updates of the whole spec?
Can we merge part of the updates or should we make sure they all land in the same release?

[radcortez]

I'd like to better understand our strategy regarding MicroProfile updates. Is this update part of a broader set of updates of the whole spec?

No, this is an update only for MP Config, still for MP 6.x

Can we merge part of the updates or should we make sure they all land in the same release?

This can be merged separately. All other specs are already at their correct version for MP 6.x.

[gsmet]

@mkouba all good for you?

[mkouba]

@mkouba all good for you?

I need to look again ;-)

[gsmet]

@mkouba let's try to get this merged this week?

[mkouba]

Looks good. I've added a few minor comments.

[radcortez]

Comments addressed!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 6625d56.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 21

📦 extensions/smallrye-reactive-messaging-kafka/deployment

✖ io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase.sseStream - History

• Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase Expecting size of: [] to be greater than or equal to 2 but was 0 within 10 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase 
Expecting size of:
  []
to be greater than or equal to 2 but was 0 within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)

[gsmet]

@radcortez what's the rationale for backporting it to 3.8? It looks a bit of a stretch.

[radcortez]

It was to make it part of the LTS version.

[gsmet]

I can see that but it's a new minor so that seems odd to push in a micro. Maybe ping me tomorrow so that we discuss it (and we will have to convince @rsvoboda :)).

[radcortez]

@rsvoboda was asking for it :))

[radcortez]

The version bump was to make the TCK compatible with CDI 4. There are no API changes.

[rsvoboda]

I remember now, there is QUARKUS-4213. Your "There are no API changes between both versions; the changes are in the TCK." comment implied to me there would be just component version update.

@radcortez changes in the code are a bit concerning, but we can discuss here what the motivation for them. Especially changes in ConfigBuildStep.

[radcortez]

The changes were required to pass a change in one of the TCK tests:
eclipse/microprofile-config#543

We validate config injection points at runtime, but in the case of @Observes @Initialized(ApplicationScoped.class), these must be performed at static init. The code changes are only for that case.

I'm okay with it if we do not backport this one.

[rsvoboda]

Thanks for the details, I would be in favor of some bake time + include this in the round for 3.8.6.