oscerd opened a new pull request, #28958: URL: https://github.com/apache/camel/pull/28958
Fixes [CAMEL-26242](https://issues.apache.org/jira/browse/CAMEL-26242), found while adding the catalog body types (CAMEL-24961). ## 1. messages/attachments failed with a ClassCastException **Was:** the generator listed every public method of `Gmail.Users.Messages`, including the accessor `attachments()`, which returns the `Attachments` sub-resource and not a request. `google-mail:messages/attachments` was in the catalog (as a method of the messages API and in the `methodName` enum), the endpoint was created, and the producer and the consumer failed on the first call with `ClassCastException: ... cannot be cast to AbstractGoogleClientRequest`. **Now:** the messages API of the module `pom.xml` excludes the accessor (`<excludeMethods>\sattachments\(\)$</excludeMethods>`, the option camel-box, camel-as2 and camel-braintree use), so `GmailUsersMessagesApiMethod` no longer has `ATTACHMENTS` and the catalog no longer lists it. An endpoint `google-mail:messages/attachments` now fails when it is created with `No matching method for messages/attachments`, for the producer and the consumer. The methods of the attachments are the `attachments` API, such as `attachments/get`, as before. The hand-written `methodName` enum of `GoogleMailConfiguration` had `attachments` and lacked `batchDelete` and `batchModify`, so the catalog validation of an endpoint such as `messages/batchDelete` reported an invalid enum value. It now lists exactly the method names of the APIs. ## Tests - New `GoogleMailApiMethodsTest` (4 tests): every method of every API builds an `AbstractGoogleClientRequest`; the `methodName` enum is the set of the method names of the APIs; `messages/attachments` is rejected when the endpoint is created; `attachments/get` reads an attachment through a fake `MockHttpTransport` client set with the client factory. - With the fix reverted (the `pom.xml`, `src/main` and `src/generated` changes), 3 of the 4 new tests fail on assertions: `messages/attachments` is listed as a method that builds no request, the enum differs from the method names, and the endpoint is created. The one that passes is `attachments/get`, which checks the way that already worked. - Module tests: 64 run, 0 failures. ## Docs and generated files - Regenerated `GmailUsersMessagesApiMethod`, `GmailUsersMessagesEndpointConfiguration` and `google-mail.json` (the messages API without `attachments`, the `methodName` enum), copied into the catalog. The regeneration also renumbers the `index` of `userId` in `messages/gmailImport`, `messages/insert` and `messages/send` (the current generator lists an overloaded method once per signature, as `drafts` already shows). - The `methodName` enum change also regenerates the endpoint DSL javadoc (`GoogleMailEndpointBuilderFactory` and `StaticEndpointBuilders`). - No change to the component doc, which does not name the method. - No upgrade guide entry: `messages/attachments` never worked. ## Not changed - The fix is in the module configuration, not in camel-api-component-maven-plugin. Of the Google API components, only google-mail (`messages/attachments`) and google-sheets (`spreadsheets/developerMetadata`, `sheets` and `values`, CAMEL-26243) list such accessors; google-calendar and google-drive do not, and the stream components have no generated methods. 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]
