oscerd opened a new issue, #9051:
URL: https://github.com/apache/camel-quarkus/issues/9051
`CamelDebugProcessor` and `DebugProcessor` both decide whether debug support
is active by testing for the *presence* of a property rather than its value.
**`extensions-core/core/.../CamelDebugProcessor.java:40-45`**
```java
return
StreamSupport.stream(ConfigProvider.getConfig().getPropertyNames().spliterator(),
false)
.anyMatch(key -> key.startsWith("camel.debug"));
```
The whole class is `@BuildSteps(onlyIf =
CamelDebugConfigurationPresent.class)` and unconditionally produces
`AllowJNDIBuildItem`. Setting `camel.debug.enabled=false` — a natural way to
pin debugging off for a production build — still matches, so JNDI support is
still allowed in.
**`extensions/debug/.../DebugProcessor.java:70-79`**
`DebugEnabled` additionally reads the bare `camel.debug.enabled` property
through `ConfigProvider` at augmentation time. That maps to the
`CAMEL_DEBUG_ENABLED` environment variable, so an ambient value in the build
environment enables the debugger and produces
`NativeMonitoringBuildItem(JMXSERVER/JMXCLIENT)` without ever appearing in the
typed `quarkus.camel.*` config that the build report records.
**Suggested fix**
- Resolve the boolean value in
`CamelDebugConfigurationPresent.getAsBoolean()` instead of testing key presence.
- Gate `DebugEnabled` on the typed `quarkus.camel.*` build-time config so
enablement is explicit and auditable.
--
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]
