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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to