Croway opened a new pull request, #26102: URL: https://github.com/apache/camel/pull/26102
## Summary `DoclingEndpoint` stores the `docling:<operationId>` URI path segment (e.g. `docling:EXTRACT_STRUCTURED_DATA`, matching the component's own documented syntax `docling:operationId`), but `DoclingComponent` never applied it to `DoclingConfiguration.operation`, and `DoclingProducer.getOperation()` only consults the `CamelDoclingOperation` header or the configured/default operation (`CONVERT_TO_MARKDOWN`). As a result, an endpoint such as: ``` docling:EXTRACT_STRUCTURED_DATA?useDoclingServe=true&doclingServeUrl=...&outputFormat=json ``` silently performs `CONVERT_TO_MARKDOWN` instead - the URI path segment is effectively ignored unless the operation is *also* passed via the `operation` query parameter or the `CamelDoclingOperation` header (the pattern already used by this component's own docs/tests, e.g. `docling:convert?operation=CONVERT_TO_MARKDOWN`). I hit this concretely while testing the `docling` example in [camel-spring-boot-examples](https://github.com/apache/camel-spring-boot-examples): a `document-metadata-extractor` route using `docling:EXTRACT_STRUCTURED_DATA?...&outputFormat=json` was writing markdown text into `.json` files (invalid JSON), because it was actually always running `CONVERT_TO_MARKDOWN`. - `DoclingComponent.createEndpoint()` now parses `operationId` into a `DoclingOperations` value and applies it to the endpoint's configuration *before* `setProperties()` runs, so an explicit `?operation=...` query parameter still takes precedence, and an `operationId` that isn't a recognized operation name (used as a purely descriptive endpoint id) is silently ignored rather than failing endpoint creation. - Added regression tests in `DoclingComponentTest` covering: `operationId` selecting the operation, an explicit `operation` parameter overriding a recognized `operationId`, and an unrecognized `operationId` being ignored in favor of the `operation` parameter. Related, not fixed here: once the operation is dispatched correctly, `EXTRACT_STRUCTURED_DATA` (and `CONVERT_TO_JSON` in docling-serve mode) sets the exchange body to a `DoclingDocument` POJO regardless of `outputFormat`, and there's no registered type converter to `String`/bytes for it - callers need to marshal it explicitly (e.g. via `camel-jackson`) before handing it to a byte-oriented endpoint like `file:`. Happy to file that as a separate follow-up if useful. ## Test plan - [x] `mvn -o test -Dtest='!*IT'` in `components/camel-ai/camel-docling` - all unit tests pass, including the new regression tests - [x] Reproduced against a live `docling-serve` container via the `camel-spring-boot-examples` docling example: before the fix, `EXTRACT_STRUCTURED_DATA` silently ran `CONVERT_TO_MARKDOWN`; after the fix, it correctly dispatches to structured-data extraction - [x] Verified the pre-existing `docling:convert?operation=...` style (used elsewhere in this component's tests/docs) is unaffected 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Hs6c6LpuL8ZZ3gaSXwt7CS -- 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]
