Fix RESTEasy Classic GZIP max input in native mode

[michalvavrik]

Quarkus QE tried to test #39828 in native mode but it doesn't work because https://github.com/quarkusio/quarkus/blob/main/extensions/resteasy-classic/resteasy/runtime/src/main/java/io/quarkus/resteasy/runtime/standalone/ResteasyConfigurationMPConfig.java is executed during the runtime while https://github.com/quarkusio/quarkus/blob/main/extensions/resteasy-classic/resteasy-common/deployment/src/main/java/io/quarkus/resteasy/common/deployment/ResteasyCommonProcessor.java#L127 is a build-time property. I propose to just convert whole config to the build-time runtime-fixed, but there are more fine-grained approaches possible.

See failure here: https://github.com/quarkus-qe/quarkus-test-suite/actions/runs/9410317682/job/25922118169

[michalvavrik]

the failure is related, but it is also very strange as it is set via resteasy.gzip.max.input=5000 which suggests that current behavior is different when you do quarkus.resteasy.gzip.max.input=5000.

[michalvavrik]

the failure is related, but it is also very strange as it is set via resteasy.gzip.max.input=5000 which suggests that current behavior is different when you do quarkus.resteasy.gzip.max.input=5000.

It seems that previous PR added fix but that fix also failed contract established by GreetingResourceTest#testConfig unit test so if #39828 had tests, it would fail this CI. I assume that RESTEasy-specific tests have priority.

[gsmet]

I added some comments inline. I'm not sure I understand what the problem is and what you are trying to test.

[michalvavrik]

I added some comments inline. I'm not sure I understand what the problem is and what you are trying to test.

I am starting to think I should had created issue instead of PR. Sorry, it felt like very trivial. I am trying to fix GZIP in a native mode where it doesn't work. (AKA creating issue first is probably better approach to discuss the issue).

[gsmet]

A PR is perfectly fine, don't worry.

I'm good with the PR except for the added test that looks very odd to me. I would refrain from adding this.

We would probably need a test that actually checks the behavior, makes sure we don't have the warning and so on. But I'm not sure it's worth the hassle.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 5d0a210.

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

📦 integration-tests/reactive-messaging-kafka

✖ io.quarkus.it.kafka.KafkaConnectorTest.testFruits - History

• Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <6> but was: <5> within 10 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <6> but was: <5> 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:1006)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testFruits(KafkaConnectorTest.java:63)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)

[gsmet]

Thanks!