Bruno Gonçalves created CAMEL-25262:
---------------------------------------
Summary: xtokenize via dynamic language: in YAML DSL NPEs; Choice
workaround fails because all branches compile at startup
Key: CAMEL-25262
URL: https://issues.apache.org/jira/browse/CAMEL-25262
Project: Camel
Issue Type: Bug
Components: camel-stax, camel-yaml-dsl
Affects Versions: 4.22.1, 4.22.0, 4.23.0
Reporter: Bruno Gonçalves
This is a follow-up to CAMEL-24572
(https://issues.apache.org/jira/browse/CAMEL-24572).
CAMEL-24572 was resolved as Fixed for 4.22.1 / 4.23.0, but the only change was
documentation (PR https://github.com/apache/camel/pull/25977 / commit 73a1823).
The runtime failure reported there is still present on 4.22.1, 4.23.0, and
current main. There was no linked code fix on the JIRA.
*== Problem 1 (original CAMEL-24572) ==*
*This works:*
- split:
{{ expression:}}
{{ xtokenize:}}
{{ expression: "\{{expression}}"}}
*This fails:*
- split:
{{ language:}}
{{ language: "\{{language}}"}}
{{ expression: "\{{expression}}"}}
when language resolves to xtokenize, with:
{{ Cannot load from object array because "properties" is null}}
Root cause: LanguageExpression goes through
{{{}ExpressionReifier.createExpression(Language, String){}}}, which calls
{{language.createExpression(exp)}} with no properties array.
In XMLTokenizeLanguage.createExpression(...):
{{ Object obj = properties[4]; // NPE when properties == null}}
(see components/camel-stax/.../XMLTokenizeLanguage.java — still present on main)
Typed YAML works because XMLTokenizerExpressionReifier builds a 5-element
properties array.
The generic language: path does not. Other languages tolerate null properties;
xtokenize does not.
Suggested fix: null-check properties before properties[4], e.g. use the existing
LanguageSupport.property(...) helper (or equivalent) instead of a raw array
access.
*== Problem 2 (workaround that does not work) ==*
To avoid the dynamic language: path, we tried a Choice with one When per
language
(xpath / jsonpath / simple / tokenize / xtokenize), each using the typed
expression form.
That fails at route create time for non-xpath languages, because Camel compiles
every Choice branch during route initialization — not only the matching When.
Example: {{language=jsonpath, expression=$[*]}}
Saxon still compiles the xpath branch with {{$[*]}} and fails with:
{{javax.xml.xpath.XPathExpressionException:}}
{{net.sf.saxon.trans.XPathException: expected "<name>", found "["}}
So Choice cannot be used as a kamelet/template workaround for dynamic language
selection when expressions are not valid across all languages.
*== Ask ==*
1. Please reopen or supersede CAMEL-24572 with a real runtime fix for null
properties in XMLTokenizeLanguage when invoked via LanguageExpression /
language.createExpression(String).
2. Confirm whether dynamic language: "\{{language}}" with a placeholder is a
supported YAML DSL pattern for languages that need typed options (xtokenize,
and similarly tokenize with token=, etc.). If not, documenting that limitation
would help; if yes, the NPE should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
