CAMEL-20199: Replace synchronized with ReentrantLock in OAuth and security components

[gnodet]

Summary

Claude Code on behalf of gnodet

Part of CAMEL-20199 (migrate from synchronized to explicit lock constructs).

This PR replaces synchronized blocks and methods with ReentrantLock in four OAuth and security component files:

• KeycloakPublicKeyResolver (camel-keycloak): refreshKeys() converted from synchronized method to ReentrantLock
• DefaultOAuthTokenValidationFactory (camel-oauth): Discovery lock map changed from ConcurrentMap<String, Object> with synchronized(lock) to ConcurrentMap<String, ReentrantLock> with explicit lock/unlock
• JwksCache (camel-oauth): Both refreshJwkSet() and fetchAndCache() converted from synchronized blocks to ReentrantLock
• KeyRotationScheduler (camel-pqc): checkAndRotate() converted from synchronized method to ReentrantLock

All conversions follow the standard lock.lock(); try { ... } finally { lock.unlock(); } pattern.

Test plan

• camel-oauth tests pass (119 tests, 0 failures)
• camel-keycloak tests pass (122 tests, 0 failures)
• camel-pqc tests pass (210 tests, 0 failures)

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-keycloak
• components/camel-oauth
• components/camel-pqc

---

🔬 Scalpel shadow comparison — Scalpel: 11 tested, 29 compile-only — current: 11 all tested

Maveniverse Scalpel detected 40 affected modules (current approach: 11).

⚠️ Modules only in Scalpel (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

Skip-tests mode would test 11 modules (3 direct + 8 downstream), skip tests for 29 (generated code, meta-modules)

Modules Scalpel would test (11)

• camel-jbang-mcp
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-keycloak
• camel-launcher-container
• camel-oauth
• camel-pqc
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin

Modules with tests skipped (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

All tested modules (40 modules)

• Camel :: All Components Sync point
• Camel :: Assembly
• Camel :: Catalog :: CSimple Maven Plugin (deprecated)
• Camel :: Catalog :: Camel Catalog
• Camel :: Catalog :: Camel Report Maven Plugin
• Camel :: Catalog :: Camel Route Parser
• Camel :: Catalog :: Console
• Camel :: Catalog :: Dummy Component
• Camel :: Catalog :: Lucene (deprecated)
• Camel :: Catalog :: Maven
• Camel :: Catalog :: Suggest
• Camel :: Component DSL
• Camel :: Coverage
• Camel :: Docs
• Camel :: Endpoint DSL
• Camel :: Endpoint DSL :: Support
• Camel :: Integration Tests
• Camel :: JBang :: Core
• Camel :: JBang :: Integration tests
• Camel :: JBang :: MCP
• Camel :: JBang :: Main
• Camel :: JBang :: Plugin :: Edit
• Camel :: JBang :: Plugin :: Generate
• Camel :: JBang :: Plugin :: Kubernetes
• Camel :: JBang :: Plugin :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Testing
• Camel :: JBang :: Plugin :: Validate
• Camel :: Kamelet Main
• Camel :: Keycloak
• Camel :: Launcher
• Camel :: Launcher :: Container
• Camel :: OAuth
• Camel :: PQC
• Camel :: YAML DSL
• Camel :: YAML DSL :: Deserializers
• Camel :: YAML DSL :: Maven Plugins
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

Looks good ✅

Clean, correct mechanical conversion of synchronized blocks/methods to ReentrantLock across four OAuth and security component files, following the standard lock-try-finally-unlock pattern established in CAMEL-20199. No semantic changes, no regressions, CI green.

Key observations:

• All four conversions correctly preserve the original synchronization scope. Instance-level synchronized methods become instance-level ReentrantLock fields. Per-key synchronized(lock) blocks using ConcurrentMap<String, Object> correctly change the map value type to ReentrantLock.
• No external code synchronizes on the this monitor of KeycloakPublicKeyResolver or KeyRotationScheduler, so the switch from intrinsic monitors to explicit locks has no observable impact on callers.
• The clear() / clearDiscoveryCache() methods that wipe the lock maps still work identically — a thread holding a removed lock completes normally; new requests create fresh locks.

Pre-existing note (not a regression): KeycloakPublicKeyResolver.clearCache() modifies keyCache and lastRefreshTime without holding the lock, which could race with a concurrent refreshKeys(). This was never synchronized before this PR either.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet