[PR] Fixes #9051. Resolve camel.debug.enabled instead of testing for key presence [camel-quarkus]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd opened a new pull request, #9065:
URL: https://github.com/apache/camel-quarkus/pull/9065

   Fixes #9051.
   
   `CamelDebugProcessor.CamelDebugConfigurationPresent` decided whether the class's build steps ran by scanning for *any* property name starting with `camel.debug`:
   
   ```java
   return StreamSupport.stream(ConfigProvider.getConfig().getPropertyNames().spliterator(), false)
           .anyMatch(key -> key.startsWith("camel.debug"));
   ```
   
   Because that tests presence rather than value, `camel.debug.enabled=false` still matched and still produced `AllowJNDIBuildItem`. So did any unrelated `camel.debug.*` key. The supplier now resolves the boolean, and is renamed `CamelDebugEnabled` to match what it actually tests.
   
   **Scope — `DebugProcessor` is deliberately unchanged.**
   
   The issue also raised `DebugProcessor.DebugEnabled` reading the bare `camel.debug.enabled` property through `ConfigProvider`. That read is intentional and must stay: it is the camel-main way to enable debugging, it has a dedicated test (`DebugEnabledFromCamelMainTest`), and `integration-tests/main` and `integration-tests/management` both rely on it. `ManagementProcessor` reads the same property. Removing it would break all of those.
   
   **Tests**
   
   `CamelDebugEnabledTest` covers the supplier directly, including the two cases that were wrong before:
   
   | Case | Expected |
   |---|---|
   | unconfigured | not enabled |
   | `camel.debug.enabled=true` | enabled |
   | `camel.debug.enabled=false` | not enabled |
   | unrelated `camel.debug.*` key only | not enabled |
   | `camel.debug.enabled=false` + another `camel.debug.*` key | not enabled |
   
   Verified as a real regression test: against the previous implementation 4 of the 5 fail with `expected: <false> but was: <true>`; all 5 pass with this change.
   
   The existing debug extension tests still pass — `DebugEnabledTest`, `DebugEnabledFromCamelMainTest` and `DebugDisabledTest` are all green. `DebugDevModeTest` fails in my local environment, but it fails identically on a pristine `main` checkout for an unrelated local Maven repository reason (it resolves a stale `camel-quarkus-cli-connector-deployment:3.23.0-SNAPSHOT`), so it is not affected by this change.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fixes #9051. Resolve camel.debug.enabled instead of testing for key presence [camel-quarkus]

["jamesnetherton (via GitHub)" <gi...@apache.org>]

jamesnetherton merged PR #9065:
URL: https://github.com/apache/camel-quarkus/pull/9065


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fixes #9051. Resolve camel.debug.enabled instead of testing for key presence [camel-quarkus]

["oscerd (via GitHub)" <gi...@apache.org>]

oscerd commented on PR #9065:
URL: https://github.com/apache/camel-quarkus/pull/9065#issuecomment-5425453621

   `functional-extension-tests` was failing on this PR and it was my fault, not a flake.
   
   `CamelDebugEnabledTest` drove the supplier through system properties and released the config registered for the class loader after each case, so that SmallRye would pick the new values up. Surefire shares one JVM, so that left everything after it without a configuration:
   
   ```
   java.lang.IllegalArgumentException: SRCFG00015: No configuration is available for this class loader
   	at io.quarkus.test.QuarkusDevModeTest.beforeEach(QuarkusDevModeTest.java:302)
   ```
   
   `CamelDevModeProfileTest` and `CamelDevModeSingletonBeanTest` both died on it. My own five assertions passed throughout, and running the class on its own passed too, which is exactly how it got through review locally.
   
   Fixed by extracting `isDebugEnabled(Config)` from the supplier. `getAsBoolean()` still passes `ConfigProvider.getConfig()` into it, so runtime behaviour is unchanged, but each test case now builds its own `SmallRyeConfig` and touches no global state.
   
   The whole `camel-quarkus-core-deployment` suite passes locally now — 78 tests, 0 failures, 0 errors, against `Errors: 2` before. `./mvnw clean install -DskipTests` from the root is also green with no regenerated artifacts left behind.
   
   The test is still a genuine regression test, and hermetic now: 3 of the 5 cases fail against the previous presence-scan implementation. It used to be 4, because `notEnabledWhenUnconfigured` only failed thanks to `camel.debug.*` properties leaking in from sibling cases — the very problem this removes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org