[
https://issues.apache.org/jira/browse/CAMEL-25262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Gonçalves updated CAMEL-25262:
------------------------------------
Description:
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). 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.
was:
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). 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.
> xtokenize via dynamic language: in YAML DSL NPEs
> ------------------------------------------------
>
> 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.0, 4.22.1, 4.23.0
> Reporter: Bruno Gonçalves
> Priority: Minor
>
> 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). 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)
