WMK666666 opened a new pull request, #29595:
URL: https://github.com/apache/camel/pull/29595
The component docs have a **Using headers to control processing** section
that sets three headers per
message on a plain `docling:` endpoint:
```java
.setHeader("CamelDoclingOperation",
constant(DoclingOperations.CONVERT_TO_HTML))
.setHeader("CamelDoclingEnableOCR", constant(true))
.setHeader("CamelDoclingOCRLanguage", constant("es"))
.to("docling:CONVERT_TO_MARKDOWN") // Operation will be overridden by header
```
`CamelDoclingOperation` is honoured. The two OCR headers are declared in
`DoclingHeaders` with
`@Metadata`, documented in that section (and in the YAML tab next to it),
and read by nothing: a search over
`src/main` finds no use of `DoclingHeaders.ENABLE_OCR` or
`DoclingHeaders.OCR_LANGUAGE` outside their
declaration. The example therefore did nothing — every message was OCRed
exactly as the endpoint was
configured, whichever header the route set.
### Change
`addOcrArguments` takes the exchange now, and the two headers override
`enableOCR` and `ocrLanguage` for
that message; unset headers fall back to the endpoint configuration as
before. This is the same shape as
`CamelDoclingUseAsyncMode`, which already overrides `useAsyncMode` per
message.
```java
Boolean enableOcr = exchange.getIn().getHeader(DoclingHeaders.ENABLE_OCR,
Boolean.class);
if (enableOcr == null) {
enableOcr = configuration.isEnableOCR();
}
```
The case worth having is a route that mostly sees text PDFs but occasionally
a scanned attachment: it can
turn OCR on for that one message instead of adding a second endpoint.
Symmetrically, an endpoint with OCR
on can skip it for a message that does not need it.
### Scope
Only the CLI command is touched. With `useDoclingServe=true` the OCR options
are built by
`applyConfigurationToOptions` from the endpoint configuration and no
exchange is in scope there, so a
per-message override on that path needs its own change; the documented
example is a plain `docling:`
endpoint, which runs the CLI.
`CamelDoclingAsyncPollInterval` and `CamelDoclingProcessingOptions` are dead
in the same way. They are not
touched here: the poll interval is a property of the client built at
startup, so it cannot be overridden
per message without rebuilding the client, and
`CamelDoclingProcessingOptions` has no documented meaning to
implement.
### Tests
`DoclingOcrHeadersTest` builds the CLI command for a message with and
without the headers, and for an
endpoint whose options say the opposite, so it fails if the headers stop
winning:
| case | command contains |
|---|---|
| no headers, default endpoint | `--ocr-lang en` |
| `CamelDoclingEnableOCR=false` | `--no-ocr`, no `--ocr-lang` |
| `CamelDoclingOCRLanguage=es` | `--ocr-lang es` |
| endpoint `enableOCR=false&ocrLanguage=de`, headers `true`/`es` |
`--ocr-lang es`, no `--no-ocr` |
Reverting `addOcrArguments` to read only the configuration fails the last
three and leaves the first green.
`mvn -pl components/camel-ai/camel-docling test`: 90 tests, 2 failures, both
`DoclingCustomArgsValidationTest`
on Windows (`/etc/cron.d` is not an absolute path there), which fail the
same way without this change.
--
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]
