oscerd opened a new pull request, #28960: URL: https://github.com/apache/camel/pull/28960
Fixes [CAMEL-26244](https://issues.apache.org/jira/browse/CAMEL-26244), found while adding the catalog body types (CAMEL-24961). ## 1. drive-files/export always returned a null body **Was:** `Drive.Files.Export` is an `AbstractGoogleClientRequest<Void>`: its content is only reachable through the `executeMedia...` methods. The producer and the consumer only called `execute()`, which downloads the response and returns null, so the body after `drive-files/export` was always null. `drive-files/get` with `alt=media` (the `CamelGoogleDrive.alt` header) downloaded the content and then failed to read it as the JSON of a `File` (`MalformedJsonException`). **Now:** a new package-private `GoogleDriveRequestHelper`, used by the producer and the consumer, calls `executeMediaAsInputStream()` for `drive-files/export`, and for `drive-files/get` and `drive-revisions/get` when `alt` is `media` (`Revisions.Get` downloads the content of a revision the same way). The body is the content as an `InputStream`, byte for byte. Every other request still calls `execute()`, so `drive-files/get` without `alt=media` still gives the `File` metadata. Who closes the stream: it holds the HTTP connection until it is read to the end or closed. - In a route, stream caching (on by default) reads it into the stream cache before the next step and closes it. - The producer does not close it when the exchange is done. The caller of a `ProducerTemplate`, also through a route that ends with the producer, reads the body after the exchange is done, so closing it on completion would hand that caller a closed stream. The reader closes it, as with the `getObject` stream of camel-aws2-s3. - The consumer owns its exchange, so it closes the stream when the exchange is done (an on-completion), whether the route read it or not. The `@BodyTypes` (`producerOut` and `consumerOut` now include `stream`) and the component doc ("Downloading the content of a file", with an export and a download route) say this. ## 2. FileConverterIT used drive-files/insert, which Drive v3 does not have **Was:** the IT sent to `google-drive://drive-files/insert?inBody=content`, and then expected the type converter to turn the returned `File` into the uploaded text. That converter (`downloadContentAsString`, which used the Drive v2 `downloadUrl`) was removed when the component moved to Drive v3 (CAMEL-19626). **Now:** the IT uses `drive-files/create?inBody=content` (`content` is the name of the parameter of `create`), checks the name of the created file, and downloads its content with `drive-files/get` and `CamelGoogleDrive.alt=media` (item 1) to compare it with the text it wrote. It compiles; it needs Google credentials, so it was not run. The hand-written `methodName` enum of `GoogleDriveConfiguration` still listed the Drive v2 names (`insert`, `patch`, `touch`, `trash`, `untrash`, `getIdForEmail`), which no API of the component has, and lacked `create`, `export`, `download`, `emptyTrash`, `generateIds`, `getStartPageToken`, `hide`, `unhide`, `listLabels` and `modifyLabels`. So the catalog validation accepted `drive-files/insert` and reported `drive-files/create` and `drive-files/export` as invalid enum values. It now lists exactly the method names of the APIs. ## Tests - New `GoogleDriveMediaContentTest` (7 tests) with a fake `MockHttpTransport` client set with the client factory, and binary content (0xff 0xfe 0x00 ...): the producer gives the content of `drive-files/export`, of `drive-files/get` with `alt=media` and of `drive-revisions/get` with `alt=media`, and sends `alt=media`; `drive-files/get` without it still gives the `File`; a `ProducerTemplate` caller of a route that ends with the export reads the content after the exchange is done; the consumer of `drive-files/export` gives the content; with stream caching off, the consumer closes the stream when the exchange is done. - New `GoogleDriveApiMethodsTest`: the `methodName` enum is the set of the method names of the APIs. - With the `src/main` and `src/generated` changes reverted, 7 of the 8 new tests fail: 5 on assertions (null body for export, producer and consumer; the enum) and 2 with the old `MalformedJsonException` for `get` with `alt=media`. The one that passes is `drive-files/get` without `alt=media`, which checks that the metadata call is unchanged. - Module tests: 14 run, 0 failures, 2 skipped (they need credentials). ## Docs and generated files - Component doc: new section "Downloading the content of a file". The body types are updated, and the regenerated `google-drive.json` (body types, `methodName` enum) is copied into the catalog with the doc. - The `methodName` enum change also regenerates the endpoint DSL javadoc (`GoogleDriveEndpointBuilderFactory` and `StaticEndpointBuilders`). - No upgrade guide entry: `drive-files/export` gave null, and `get` with `alt=media` failed, so nobody could rely on them; the removed enum names never worked with Drive v3. ## Not changed - `alt` stays a header (`CamelGoogleDrive.alt`), as the generator only lists the setters of the request class, not the `alt` of `DriveRequest`; no new endpoint option was added. **Open question:** add an option for it? - `DriveFilesIT` is also stale (routes such as `direct://COPY` and `direct://INSERT` are not defined, and `testTouch`/`testTrash` call Drive v2 methods); it is not named by the issue and is left as is. Main only, as the other fixes of the CAMEL-24961 follow-ups. _Claude Code on behalf of Andrea Cosentino (oscerd)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
