[
https://issues.apache.org/jira/browse/CAMEL-18576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616410#comment-17616410
]
Claus Ibsen edited comment on CAMEL-18576 at 10/12/22 1:09 PM:
---------------------------------------------------------------
Nicolas, that look good for users that can edit their input and escape the JSon
input.
But for out of the box, we should ideally have a way.
I have run a full test with nested placeholder disabled and we do not use it
very much - only in some special tests for camel-jasypt.
I have also not seen real world use-cases with nested placeholders. Its only
when you may go very fine grained and have a placeholder for hostname, and
another for port, and then have a 3rd where you concat them together.
But lets keep this open for a while and think about if we can have a nicer
solution out of the box - but even then this problem is only when you have
double {{ and }} which ought to be more rare for even JSon payloads.
[~MarcoMartins] do you see the double `{{` used more often in your ES queries ?
was (Author: davsclaus):
Nicolas, that look good for users that can edit their input and escape the JSon
input.
But for out of the box, we should ideally have a way.
I have run a full test with nested placeholder disabled and we do not use it
very much - only in some special tests for camel-jasypt.
I have also not seen real world use-cases with nested placeholders. Its only
when you may go very fine grained and have a placeholder for hostname, and
another for port, and then have a 3rd where you concat them together.
But lets keep this open for a while and think about if we can have a nicer
solution out of the box - but even then this problem is only when you have
double `{{` and `}}` which ought to be more rare for even JSon payloads.
[~MarcoMartins] do you see the double `{{` used more often in your ES queries ?
> kamelets - JSon Property value can't finish with }}
> ---------------------------------------------------
>
> Key: CAMEL-18576
> URL: https://issues.apache.org/jira/browse/CAMEL-18576
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: Marco Martins
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 3.20.0
>
>
> Hi, I'm using Quarkus Camel 2.12.3.Final with YAML DSL and Kamelets and I
> have a problem passing a JSON value through URI as a query parameter when
> trying to use the
> [elasticsearch-search-source|https://github.com/apache/camel-kamelets/blob/main/kamelets/elasticsearch-search-source.kamelet.yaml]
> with a basic query:
> {code:json}
> {"query":{"match_all":{}}} {code}
> Example on the YAML DSL:
> * Scenario 1
> {code:yaml}
> query: '{"query":{"match_all":{}}}'{code}
> Gives
> {noformat}
> java.lang.IllegalArgumentException: Missing {{ from the text:
> {"query":{"match_all":{}}}
> {noformat}
> * Scenario 2
> {code:yaml}
> query: '{{myQuery}}'{code}
> Gives
> {noformat}
> java.lang.IllegalArgumentException: Missing {{ from the text:
> {"query":{"match_all":{}}}
> {noformat}
> * Scenario 3
> {code:yaml}
> query: '#property:myQuery'{code}
> Gives
> {noformat}
> java.lang.IllegalArgumentException: Property with key myQuery not found by
> properties component
> {noformat}
> But using debug I've checked that the above exception occurs due to the same
> {noformat}
> java.lang.IllegalArgumentException: Missing {{ from the text:
> {"query":{"match_all":{}}}
> {noformat}
> * Scenario 4
> I've also tried to change the Kamelet YAML definition to use the RAW value
> directly
> {code:yaml}
> - set-body:
> constant: "RAW({{myQuery}})"{code}
> With the same result
> {noformat}
> java.lang.IllegalArgumentException: Missing {{ from the text:
> {"query":{"match_all":{}}}
> {noformat}
> I have a workaround if I add spaces in JSON like below it works in scenarios
> 1 and 2.
> {code:json}
> { "query": { "match_all": { } } } {code}
> My point is, why do I have to change the JSON value to adapt to the Camel
> parser? Also, there also might exist some other use case where the value
> can't be changed.
> Why don't you simply have a function that does not try to resolve properties
> as placeholders recursively? For example:
> {code:yaml}
> query: '{{raw:myQuery}}'{code}
> Or with a default value
> {code:yaml}
> query: '{{raw:myQuery:{"query":{"match_all":{}}}}}'{code}
> Or at least have a way to escape curly brackets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)