Salvatore Mongiardo created CAMEL-25231:
-------------------------------------------
Summary: 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
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)
