davsclaus opened a new pull request, #28764: URL: https://github.com/apache/camel/pull/28764
_Claude Code on behalf of davsclaus_ Fixes [CAMEL-26429](https://issues.apache.org/jira/browse/CAMEL-26429), found while measuring the startup of the CLI for [CAMEL-23810](https://issues.apache.org/jira/browse/CAMEL-23810). The third of three; with #28762 (CAMEL-26427) and #28763 (CAMEL-26428) `camel version` goes from about 920 ms to about 190 ms. Most commands of the CLI turn the logging off when they start (`CamelCommand.configureLoggingOff()`), which configured log4j (`RuntimeUtil.configureLog("off", ...)`): about 215 ms in a new JVM, of which about 40 ms registers the MBeans of log4j. Most commands never log, such as `camel version`, `camel ps` or `camel config list`. ## Changes - **`RuntimeUtil.configureLog` with the logging off does not configure log4j.** It sets `log4j2.configurationFile` to `log4j2-off.properties` (new): the configuration without color, with the logging off. log4j configures itself with it when something first logs. Everything else is as before: - When log4j is configured already (something logged before), it configures as before. - When the logging is configured again in the same command (such as `camel export` after the logging off), log4j is configured first as the command that turned the logging off would have (the configuration without color, root logger off), and then as before: the command keeps the appenders it started with. - When a CLI that runs several commands (`camel ask`, `camel shell`, the monitor) runs another one, it logs as on its own, as before (`RuntimeUtil.newCommand()`); a next command with the logging off still does not configure log4j. - The system properties (`pid`, the log directory, the JMX of log4j) are set as before. - **The effect needs #28763.** On `main` the CLI creates all its commands, and creating them configures log4j already (something logs), so the logging off configures it at once, as before. With the commands created only when they run, `camel version` takes about 177 ms from the start to the exit instead of 328 ms. ## Measured On JDK 25 (Apple M4 Pro), with the classes of the launcher on a flat classpath, as JBang runs the CLI, median of 5 runs, with #28763 (from the start to the exit; wall time of 3 runs in brackets): | | #28763 | #28763 and this | | --- | --- | --- | | `camel version` | 328 ms | 177 ms (190 ms) | | `camel ps` | 324 ms | 174 ms (190 ms) | | `camel config list` | 323 ms | 166 ms (180 ms) | | `camel get` | | 227 ms (240 ms) | A command that logs (`camel catalog`, `camel doctor`, `camel dependency`) takes the same time as before, as log4j is configured when it first logs. ## Tests - `RuntimeUtilDeferredLoggingTest` (new), each case in a new JVM, as log4j is configured once in a JVM: - the logging off does not configure log4j; - when something logs, log4j configures itself with the logging off (`log4j2-off.properties`, root logger off, the appenders of the configuration without color), and nothing reaches the console; - a command that configures the logging again logs with the appenders it started with (also after something logged); - the next command of a CLI that runs several commands with the logging off still does not configure log4j, and an export after it logs to its file only; - when something logged before, the logging off configures log4j at once. Three of the cases fail without the change. - `LogConfigurationTest`: the log file of `log4j2-off.properties` is the one of the CLI, as for the other configurations. - `RuntimeUtilLoggingTest` passes unchanged. - camel-jbang-run: 230 tests pass. camel-jbang-core: 2428 tests; the only failures fail on `main` locally too (the 9 tests of the AI tools about the elvis operator of Simple, and `CatalogDocJavaExamplesTest`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0128ThHB3iQdrvSRLVBGRrdP -- 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]
