[jira] [Commented] (CAMEL-24852) camel-jbang - the validator reports a resource:classpath: file that sits next to the route, and a ${} placeholder in a file endpoint's directory

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-24852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18117328#comment-18117328 ] 

Claus Ibsen commented on CAMEL-24852:
-------------------------------------

Why classpath: fails for the groovy file only: camel run sorts the files of the directory by kind. Files it does not know (an .xsl stylesheet, a .json sample) go on the classpath, so resource:classpath:packing-slip.xsl works. A .groovy file is a known kind: it is taken as a Groovy source to compile (and reloaded in --dev), and is not put on the classpath. So the same syntax works for the stylesheet and fails for the script next to it, and the error names neither reason nor remedy.

The validator row is the cheap fix and is what this issue does. An open design question for the CLI, not done here: should camel run also put the known files (routes, scripts) on the classpath, so classpath: works for them as people used to Spring Boot and Quarkus expect? That changes what the CLI does with every file and needs a look at side effects (the same Groovy script both compiled and loadable as text).

> camel-jbang - the validator reports a resource:classpath: file that sits next to the route, and a ${} placeholder in a file endpoint's directory
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24852
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24852
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jbang
>            Reporter: Claus Ibsen
>            Priority: Major
>
> Two startup failures from the round-2 benchmark (series l2) where the validator was clean and the runtime refused the file with a message the validator could have given before the run. Both echo a message the runtime already has.
> *1. resource: pointing at a file next to the route with classpath:*
> {code:yaml}
> - setBody:
>     expression:
>       groovy:
>         expression: "resource:classpath:shipment-mapping.groovy"
> {code}
> with {{shipment-mapping.groovy}} in the same directory as the route. {{camel run}} fails with "Cannot load resource classpath:shipment-mapping.groovy" ({{FileNotFoundException}}); {{resource:file:shipment-mapping.groovy}} works. The validator (directory-aware path, the one that has the files) should check a {{resource:}} reference: if the file exists next to the route but the scheme is {{classpath:}}, say to write {{resource:file:<name>}}; if it exists nowhere, say it is not found.
> *2. a ${...} placeholder in a file endpoint's directory*
> {code:yaml}
> - to:
>     uri: "file://archived/${header.monthDir}?fileName=${header.CamelFileName}"
> {code}
> fails at startup with "Invalid directory: archived/${header.monthDir}. Dynamic expressions with ${ } placeholders is not allowed. Use the fileName option to set the dynamic expression." The endpoint checks should report a placeholder in the directory part of a file (and ftp/sftp/smb) endpoint with that message, and the toD hint where the whole uri is dynamic.
> Both in the catalog layer of {{SourceValidator}} (camel-jbang-core: EndpointChecks / a resource check), tests next to the existing ones.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)