gnodet opened a new pull request, #25239:
URL: https://github.com/apache/camel/pull/25239
## Summary
_Claude Code on behalf of @gnodet_
Migrates `TomcatReactiveExecutor` from raw `ThreadLocal` with
reflection-based cleanup to `ContextValue.newThreadLocal()`, achieving parity
with `DefaultReactiveExecutor` which was already migrated.
**What changed:**
- Replaced the `TrackingThreadLocal` inner class (which used fragile
`Thread.class.getDeclaredField("threadLocals")` reflection) with
`ContextValue.newThreadLocal("CamelTomcatReactiveWorker", ...)`
- Removed `ConcurrentHashMap<Thread, Field>` thread tracking and the
reflection-based `clearWorkers()` method
- Shutdown now uses `workers.remove()` for clean cleanup
- Refactored `Worker` class to use extracted helper methods (matching
`DefaultReactiveExecutor`'s structure)
- Dropped `public` from test class/methods per JUnit 5 conventions
**Why it matters for virtual threads:**
- The old reflection hack (`Thread.threadLocals` field access) does not work
with virtual threads
- With `ContextValue`, on JDK 25+ this automatically uses `ScopedValue`
instead of `ThreadLocal`
- Worker objects with `ArrayDeque` queues are on the routing hot path — with
raw `ThreadLocal` and virtual threads, a new Worker was created per VT and
never reused
Part of the umbrella issue
[CAMEL-20199](https://issues.apache.org/jira/browse/CAMEL-20199) (Complete
support of Virtual Threads).
## Test plan
- [x] Existing `SimpleMockTest` passes (2 tests)
- [ ] CI green
🤖 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]
