[
https://issues.apache.org/jira/browse/CAMEL-25231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125354#comment-18125354
]
Guillaume Nodet commented on CAMEL-25231:
-----------------------------------------
This issue appears to have been already fixed on the main branch by two commits:
1. *073c6cf7ec20* (CAMEL-24976): Fixed tryMatch() - the BFS super-type walk now
has a stable order (interfaces before superclass at each level, Object last),
independent of ConcurrentHashMap iteration order.
2. *4faa92ecfac6* (CAMEL-21513): Fixed tryAssignableFrom() - the last-resort
assignable match now picks the nearest converter by type-hierarchy distance,
with deterministic tiebreaking by class name. The test in this commit
explicitly references CAMEL-25231 and models the CachedCxfPayload scenario.
Together these changes eliminate all map-order-dependent converter selection
paths in TypeResolverHelper, which was the root cause of the non-deterministic
CXF payload source type selection affecting xpath, xquery, and validator
components.
Please verify and close if confirmed.
_Note: This comment was generated by an AI coding agent and requires manual
verification._
> camel-cxf / type-converter registry: non-deterministic source type selection
> for CXF payload affects xpath, xquery, validator
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25231
> URL: https://issues.apache.org/jira/browse/CAMEL-25231
> Project: Camel
> Issue Type: Bug
> Reporter: Salvatore Mongiardo
> Priority: Major
>
> When a CXF payload body is consumed by XML-processing components (xpath,
> xquery, validator, xslt), the type-converter registry non-deterministically
> picks either a StAX/SAX source or a +DOMSource+ wrapping the document
> element. The chosen source type varies between JVM runs, meaning the same
> message can be processed differently depending on which converter is loaded
> first.
> This was first observed as a trigger for the XSLT context-node bug fixed in
> CAMEL-25224, but the non-determinism in the registry is an independent
> problem: any XML consumer that receives an implicitly converted CXF payload
> is potentially affected by the inconsistent source selection, including:
> - {{camel-xpath}}
> - {{camel-xquery}}
> - {{camel-validator}}
> *Symptoms:*
> - A CXF payload processed by xpath/xquery/validator behaves differently
> across JVM restarts.
> - A StAX/SAX source is returned on some runs; a +DOMSource+ containing the
> document element (rather than the document node) is returned on others.
> - The root cause is that no stable ordering or priority is enforced in the
> type-converter registry for the converters contributing to the +Source+ type
> from CXF message payloads.
> *Expected behaviour:* The registry should consistently select the same
> converter (or a documented priority order), so that XML consumers receive a
> predictable source type regardless of JVM startup order.
> *Related:* CAMEL-25224 (camel-xslt / camel-xslt-saxon context-node fix that
> was triggered by this non-determinism)
> *References:* https://github.com/apache/camel/pull/27154
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
