allthingssecurity opened a new pull request, #29526: URL: https://github.com/apache/camel/pull/29526
# Description [CAMEL-26752](https://issues.apache.org/jira/browse/CAMEL-26752) Follow-ups of CAMEL-25911 (#28382), as agreed on the dev@ list in the thread "[DISCUSS] An internal time source in camel-util (for deterministic simulation tests)": https://lists.apache.org/thread/grhr2y5975pqp0rvoschf7d1kff0nwx7 (points 1 to 3 of JB's mail; point 4, the benchmark, goes to camel-performance-tests). Change: - **A check against direct clock calls.** `TimeSourceDirectClockCallsTest` in camel-core scans the sources of the 23 core classes that read the clock and sleep through `TimeSource` (those of CAMEL-25911, plus the send and step helpers of CAMEL-26331 / CAMEL-26338) in camel-util, camel-support, camel-core-processor and camel-base-engine. Outside comments and string literals it fails on `System.nanoTime()`, `System.currentTimeMillis()` and `Thread.sleep`, and on the same calls in another form: `Instant.now()`, `TimeUnit.X.sleep`, a method reference or a static import. The message gives the file, the line and the `TimeSource` method to use instead. Only the `SystemProvider` of `TimeSource` may call them. The list is explicit, with a comment on how to add a class. A second test fails when a class of these four modules uses `TimeSource` but is not in the list. It is a textual scan, not a parser, and it does not add the forbidden-apis plugin, which Camel does not use. It lives in camel- core because the classes span four modules, so it runs with the camel-core tests: the Jenkins build always runs them, while the incremental GitHub build of a PR that only touches camel-util or camel-support usually does not reach camel-core. camel-chaos, the one component that reads `TimeSource` directly, is not scanned: nothing was moved there, and the waits of its assertions run in real time on purpose. - **An INFO line for a non-default provider.** `TimeSource.install` logs `Installed TimeSource provider: <class>` when a provider other than the default is installed, and `Installed default TimeSource provider (replacing: <class>)` when the default is put back (also through `reset()`). Nothing is logged when the default stays installed. The lines are logged under the lock of `install`, so two installs log in their order. The provider is static, so in a shared runtime such as Karaf it would apply to every CamelContext that shares camel-util; the line makes that visible if a provider ever leaks out of a test harness. camel-util cannot know about running CamelContexts, so there is no WARN about them. camel-test-dst installs its clock for each seed and puts the previous provider back after it, so a DST test logs two INFO lines per seed, and they name `org.apache.camel.test.dst.DstClock$1` (its provider is an anonymous class). - **Javadoc and docs.** `TimeSource` stays internal. Its Javadoc now says that a component gets virtual time through the core classes it already uses (the task classes, the delayer, the throttlers, the redelivery), and that camel-chaos is the one exception. `test-dst.adoc` says the same and names the new test next to the list of core classes; its catalog copy is byte-identical. The chaos design page loses a sentence about a Javadoc change that had already been made. No behaviour change apart from the new INFO lines, which only a test harness triggers. Tests: - `TimeSourceDirectClockCallsTest` (camel-core): the scan of the listed classes and the list check pass on main. A third test checks the scanner on a snippet: direct calls and method references are found; comments, strings, a text block and literals that end with an escaped backslash, and the allowed nested class are skipped; an unterminated comment or literal fails the scan. Negative controls: with a `System.nanoTime()` and a `Thread.sleep(...)` put into `ForegroundTask`, the scan fails with `ForegroundTask.java:104: System.nanoTime(), use TimeSource.nanoTime() instead` and `ForegroundTask.java:118: Thread.sleep, use TimeSource.sleep(millis) instead`; with a probe class in camel-support that calls `TimeSource.nanoTime()`, the list check fails and names it. - `TimeSourceLogTest` (camel-util) captures the `TimeSource` logger with a log4j appender. Two tests check the two INFO lines with the provider class, and that `reset()` logs like putting the default back; on main both fail (no lines). The third test (nothing is logged while the default stays installed) is a control that also passes on main. - The new tests passed 20 of 20 runs (one JVM per run, together with `TimeSourceTest`). Module tests (offline, core reactor): camel-util 339 run, 0 failures; in camel-core the TimeSource, StopWatch, send and step helper, throttler, redelivery, delay, back-off, task and timeout map tests, 348 run, 0 failures. The formatter and import-sort plugins made no changes. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-26752](https://issues.apache.org/jira/browse/CAMEL-26752). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built the core modules with the formatter and import-sort plugins and ran the tests listed above. The catalog copy of `test-dst.adoc` was updated by hand to match the source page. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
