Claus Ibsen created CAMEL-24907:
-----------------------------------
Summary: camel-jbang - camel_eval_expression evaluates jsonpath,
jq, xpath and the other languages, not only the ones on its own classpath
Key: CAMEL-24907
URL: https://issues.apache.org/jira/browse/CAMEL-24907
Project: Camel
Issue Type: Improvement
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.23.0
{{camel_eval_expression}} evaluates against the running integration when one is
selected, and in a local scratch context otherwise. In the local context only
the languages on the MCP server's own classpath work: simple, constant, header
and the like. Everything else answers
{noformat}
{"language":"jsonpath","status":"error","error":"Unknown language 'jsonpath':
No language could be found for: jsonpath (the jsonpath language is in
camel-jsonpath; add camel-jsonpath to the classpath)"}
{noformat}
which is accurate and useless to a model: it cannot add anything to the
classpath of the server. So the one tool that could check a filter *before* it
is written refuses exactly when it would help, before the app runs.
In the camel-jbang-mcp stepwise benchmark (CAMEL-24886) the HTTP rungs filter
the stock file with {{$[?(@.sku == '${header.sku}')]}} in every example; the
model called the evaluator 23 times across three series, 8 of them ended in an
error, and it never once checked a jsonpath before writing it.
Two parts:
* download the language's component in the local scratch context the way
{{camel run}} does (the CLI has the downloader), so jsonpath, jq, xpath,
groovy, xquery and the rest can be evaluated with a sample body
* until then, say in the answer which languages the local context can evaluate
and that selecting an integration evaluates the rest, so the model knows what
to do next instead of reading about a classpath it cannot change
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
