Skip to content

Arc regex property matching#53774

Open
manovotn wants to merge 2 commits intoquarkusio:mainfrom
manovotn:arc-regex-property-matching
Open

Arc regex property matching#53774
manovotn wants to merge 2 commits intoquarkusio:mainfrom
manovotn:arc-regex-property-matching

Conversation

@manovotn
Copy link
Copy Markdown
Contributor

Fixes #53757

There are two commits.

First one adds the regex functionality. In order to avoid computing the regex repeatedly, I have added a static field into the generated bean. This however required me to change SuppressConditionGeneratorBuildItem to gain access to the ClassCreator. I am not sure if that's acceptable given it's theoretically a "public" build item.

Second commit fixes an inconsistency we already had in code regarding case-sensitivity.
For build-time properties, we were using case-insensitive approach (code) whereas runtime was using case sensitive (code).
I believe this was an oversight although it is theoretically breaking 🤷

@manovotn manovotn requested review from Ladicek and mkouba April 23, 2026 13:19
@quarkus-bot quarkus-bot Bot added the area/arc Issue related to ARC (dependency injection) label Apr 23, 2026
@mkouba
Copy link
Copy Markdown
Contributor

mkouba commented Apr 23, 2026

First one adds the regex functionality. In order to avoid computing the regex repeatedly, I have added a static field into the generated bean. This however required me to change SuppressConditionGeneratorBuildItem to gain access to the ClassCreator. I am not sure if that's acceptable given it's theoretically a "public" build item.

SuppressConditionGeneratorBuildItem is package-private so it's not part of the public API.

Second commit fixes an inconsistency we already had in code regarding case-sensitivity.
For build-time properties, we were using case-insensitive approach (code) whereas runtime was using case sensitive (code).
I believe this was an oversight although it is theoretically breaking 🤷

Yes, that's breaking. In theory, we could add StringValueMatch.EQ_IGNORE_CASE and make it default for build-time property conditions?

@Ladicek
Copy link
Copy Markdown
Member

Ladicek commented Apr 23, 2026

This however required me to change SuppressConditionGeneratorBuildItem to gain access to the ClassCreator. I am not sure if that's acceptable given it's theoretically a "public" build item.

The class has default visibility, so it's not a public build item in any way, shape or form. It seems to me that we could really use a "context accessor" here instead of a BiFunction (see BeanConfiguratorBase.CreateGeneration / DestroyGeneration / CheckActiveGeneration for an example), but since it is not public and can safely be changed, it's not a big deal.

The PR looks good, but I only took a very brief look and didn't review properly. I'll take a proper look next week.

@manovotn
Copy link
Copy Markdown
Contributor Author

SuppressConditionGeneratorBuildItem is package-private so it's not part of the public API.

Right, I totally missed that, thanks for pointing it out 🤦

Yes, that's breaking. In theory, we could add StringValueMatch.EQ_IGNORE_CASE and make it default for build-time property conditions?

This is IMO making it even worse. The idea of these properties is to be case sensitive and this way we'd add arguably useless option while still keeping the behavior broken. If you just wish to make it explicit and keep as-is, we can easily document it in the StringValueMatch class 🤷

Personally, I'd point it out as potentially breaking but still change it. To me, it is clearly an oversight.

@mkouba
Copy link
Copy Markdown
Contributor

mkouba commented Apr 23, 2026

The idea of these properties is to be case sensitive and this way we'd add arguably useless option while still keeping the behavior broken

Well, that might be obvious for users who work with case sensitive systems 🤷.

@quarkus-bot
Copy link
Copy Markdown

quarkus-bot Bot commented Apr 23, 2026

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 749fa31.

✅ 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 25

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

io.quarkus.smallrye.reactivemessaging.kafka.deployment.testing.KafkaDevServicesContinuousTestingWorkingAppPropsTestCase.testContinuousTestingScenario3 - History

  • org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/library/redis:7 - java.util.concurrent.CompletionException
Details
java.util.concurrent.CompletionException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/library/redis:7
	at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1828)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1817)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)

📦 extensions/vertx-http/deployment

io.quarkus.vertx.http.filters.GracefulShutdownFilterTest.test - History

  • Timeout waiting for response - java.lang.RuntimeException
Details
java.lang.RuntimeException: Timeout waiting for response
	at io.quarkus.vertx.http.filters.GracefulShutdownFilterTest.testWithVertxHttpClientAndHttp2AfterShutdown(GracefulShutdownFilterTest.java:85)
	at io.quarkus.vertx.http.filters.GracefulShutdownFilterTest.test(GracefulShutdownFilterTest.java:59)

⚙️ JVM Integration Tests - JDK 17

📦 integration-tests/grpc-hibernate

com.example.grpc.hibernate.BlockingRawTest.shouldAdd - History

  • Condition with Lambda expression in com.example.grpc.hibernate.BlockingRawTestBase was not fulfilled within 30 seconds. - org.awaitility.core.ConditionTimeoutException
Details
org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in com.example.grpc.hibernate.BlockingRawTestBase was not fulfilled within 30 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1129)
	at com.example.grpc.hibernate.BlockingRawTestBase.shouldAdd(BlockingRawTestBase.java:59)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)

📦 integration-tests/reactive-messaging-kafka

io.quarkus.it.kafka.KafkaConnectorTest.testPrices - History

  • Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <7> but was: <6> within 10 seconds. - org.awaitility.core.ConditionTimeoutException
Details
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <7> but was: <6> 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)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testPrices(KafkaConnectorTest.java:77)
Caused by: org.opentest4j.AssertionFailedError: expected: <7> but was: <6>
  • Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <12> but was: <6> within 10 seconds. - org.awaitility.core.ConditionTimeoutException
Details
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <12> but was: <6> 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)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testPrices(KafkaConnectorTest.java:77)
Caused by: org.opentest4j.AssertionFailedError: expected: <12> but was: <6>

⚙️ JVM Integration Tests - JDK 25

📦 integration-tests/reactive-messaging-kafka

io.quarkus.it.kafka.KafkaConnectorTest.testDataForKeyed - History

  • Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <3> but was: <4> within 10 seconds. - org.awaitility.core.ConditionTimeoutException
Details
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <3> but was: <4> 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)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testDataForKeyed(KafkaConnectorTest.java:96)
Caused by: org.opentest4j.AssertionFailedError: expected: <3> but was: <4>
  • Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <3> but was: <6> within 10 seconds. - org.awaitility.core.ConditionTimeoutException
Details
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <3> but was: <6> 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)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testDataForKeyed(KafkaConnectorTest.java:96)
Caused by: org.opentest4j.AssertionFailedError: expected: <3> but was: <6>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/arc Issue related to ARC (dependency injection) triage/flaky-test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ArC: Add support for RegEx in @LookupIfProperty stringValue

3 participants