oscerd opened a new pull request, #25733: URL: https://github.com/apache/camel/pull/25733
## Backport of #25596 Cherry-pick of #25596 onto `camel-4.22.x`. **Original PR:** #25596 **Target branch:** `camel-4.22.x` **Commits cherry-picked:** 1 (squash commit `8b95ef19002a`) ### What changed `DoclingProducer.getInputPath()` decided what a `String` message body *meant* by inspecting its prefix: `http://` / `https://` was handed to Docling as a remote URL to fetch, a leading `/` or an embedded `\` was read from the local filesystem, anything else was converted as document content. The mode was chosen implicitly and the route author had no way to influence it. The two location readings are now opt-in: | Option | Default | Effect when enabled | |---|---|---| | `allowUrlSource` | `false` | A body starting with `http://` / `https://` is fetched as a URL | | `allowFilePathSource` | `false` | A body starting with `/`, or containing `\`, is read from disk | | `inputBaseDirectory` | _(unset)_ | Local input paths must resolve inside this directory | Only a bare `String` body is gated, because only it is ambiguous. The `CamelDoclingInputFilePath` header, `File` / `byte[]` / `InputStream` bodies, and the explicit path collections used by the batch operations keep working with no opt-in. Also collapses the four independent copies of the `http://` / `https://` prefix test into a single `isRemoteSource()` helper, and renames `validateFileSize` to `validateFileSizeIfPresent` (it was wrapped in `Files.exists()` and so silently skipped a path that resolved to nothing) with a new `validateLocalInputPath` that requires the path to exist. ### Differences from the original PR - The upgrade-guide entry targets `camel-4x-upgrade-guide-4_22.adoc` (the `4_23` guide is main-only). Content is otherwise identical. Everything else is a clean cherry-pick — `camel-4.22.x` is on junit6 like main, and already carries the security-marker framework, so no further adaptation was needed. ### Verification - Full reactor `mvn clean install -DskipTests`: **BUILD SUCCESS, 684/684**, and `git status` clean afterwards (no regeneration drift). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
