CAMEL-24573: CXF REST: UnsupportedOperationException when copying fac… - #25967
Conversation
…tory bean with fixed-size features list When creating a CXF JAXRS client factory bean from a Spring bean with a fixed-size features list (e.g., from Arrays.asList()), the shallow field copy resulted in a reference to the immutable list. Subsequent attempts to append endpoint features via addAll() threw UnsupportedOperationException. Wrap the copied features list in a new ArrayList to ensure mutability while preserving the original values. Fixes CSB-10555 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet
left a comment
There was a problem hiding this comment.
Correct fix for UnsupportedOperationException when shallowCopyFieldState copies a fixed-size features list. The root cause is that ReflectionUtils.shallowCopyFieldState(bean, cfb) copies the features field via reflection, inheriting the original unmodifiable list reference. When setupCommonFactoryProperties() later calls factory.getFeatures().addAll(...) and factory.getFeatures().add(loggingFeature), both fail on a fixed-size list. Wrapping in new ArrayList<>() is the correct and minimal fix.
Test properly reproduces the issue.
Note: The same shallowCopyFieldState pattern could cause a similar issue with the properties map if someone passes an unmodifiable map (factory.getProperties().putAll(...) at line 393). Not in scope for this PR but worth noting for future hardening.
📋 PR Metadata
| Aspect | Current | Suggested |
|---|---|---|
| Labels | components |
+ bug |
| Milestone | (none) | 4.23.0 |
🔀 Backport Status
main but no backport PRs were found for:
camel-4.22.x— same vulnerable code innewInstanceWithCommonProperties()camel-4.18.x— same vulnerable code
Consider creating backport PRs or adding backport-to-camel-4.22.x / backport-to-camel-4.18.x labels.
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
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 9 tested, 27 compile-only — current: 9 all testedMaveniverse Scalpel detected 36 affected modules (current approach: 9).
|
davsclaus
left a comment
There was a problem hiding this comment.
Nice, tight fix — thanks for tracking this down. Verified independently: built camel-cxf-spring-rest and ran CxfRsSpringEndpointTest in an isolated worktree, all 4 tests pass including the new testCreateCxfRsClientFactoryBeanWithFixedSizeFeatures.
The root cause traces back cleanly: setupCommonFactoryProperties()'s factory.getFeatures().addAll(getFeatures()) (added in CAMEL-24183) combined with the older shallow-copy of the features field to produce the crash whenever the source bean's list is fixed-size (Arrays.asList()). Rewrapping only the copy (cfb) rather than mutating the original Spring bean's list is the right, minimal call.
As a bonus, this also happens to fix a latent aliasing issue: before this change, cfb.getFeatures() and the endpoint's own getFeatures() were literally the same List instance, so addAll() was silently self-appending to a list shared with the original bean — repeated createJAXRSClientFactoryBean() calls on the same endpoint would have kept growing that shared list. Not something this PR needs to address further, just worth calling out.
One small, non-blocking note: the commit message ends with Fixes CSB-10555 alongside the CAMEL-24573 reference — looks like it might be an internal tracker ID that isn't meaningful to external readers. Not a blocker, just flagging in case it wasn't intentional to include.
No test-coverage gaps, no scope drift, no upgrade-guide or catalog regeneration needed for this change.
This review does not replace specialized tools such as CodeRabbit, Sourcery, or SonarCloud.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
…tory bean with fixed-size features list Backports #25967 to camel-4.22.x, a straight cherry-pick already reviewed and merged on main. CxfRsSpringEndpoint.newInstanceWithCommonProperties() shallow-copies the features field from the source Spring bean; when that bean's features list is fixed-size (e.g. Arrays.asList()), the copy aliases the same immutable list, and a later addAll() call in setupCommonFactoryProperties() throws UnsupportedOperationException. Wraps the copied list in a new ArrayList so the copy is mutable, without touching the original Spring bean's list. Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com> Closes #25969
…tory bean, backport to camel-4.18.x Backports #25967 to camel-4.18.x. Same fix as #25969: wraps the shallow-copied features field in a new ArrayList in CxfRsSpringEndpoint.newInstanceWithCommonProperties() so a fixed-size source list (e.g. Arrays.asList()) doesn't cause UnsupportedOperationException on a later append. Not a straight cherry-pick: this branch's camel-cxf-spring-rest test module depends on camel-test-spring-junit5, not junit6, so the test's import was kept as-is. More substantially, CxfRsSpringEndpoint.setupJAXRSClientFactoryBean() on this branch never calls setupCommonFactoryProperties() (that call was added later by CAMEL-24183, not present here), so the endpoint's own features are never auto-appended to the copied list. The ported test is adapted to assert the copied feature is preserved and that the list is mutable by appending directly, rather than relying on auto-append behaviour this branch doesn't have. Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Closes #25970
…tory bean with fixed-size features list
Description
Target
mainbranch)Tracking
Apache Camel coding standards and style
mvn clean install -DskipTestslocally from root folder and I have committed all auto-generated changes.AI-assisted contributions
Co-authored-bytrailers) and the PR description identifies the AI tool used.