stn1slv opened a new pull request, #25323: URL: https://github.com/apache/camel/pull/25323
JIRA: https://issues.apache.org/jira/browse/CAMEL-24340 ### The defect `apexMethod` is documented as **"APEX method name"**, but the component uses the value verbatim as the **HTTP verb** of the Apex REST call: - `AbstractRestProcessor:637` reads the option, defaulting it to `GET` at `:640` - `:653` passes it as the first argument to `restClient.apexCall(...)` - `RestClient:243` declares that parameter as `String httpMethod` ("HTTP method to execute") - `DefaultRestClient:499` forwards it to `getRequest(httpMethod, ...)`, and `AbstractClientBase:169-171` passes it into Jetty's `HttpRequest.method(String)` There is no validation or lookup at any step. A user who follows the documentation and sets `apexMethod` to their real Apex method name, for example `getMerchandise`, makes Camel issue `GETMERCHANDISE /services/apexrest/...`, which fails. The wording dates from CAMEL-8772 (2015) and has been propagated mechanically since. **Why this is not cosmetic:** the hand-written Apex table already says "The HTTP method (e.g. GET, POST) to use", but the generated options table is included in the *same page* (`salesforce-component.adoc:58-60`, about 175 lines above), so the page contradicts itself. More importantly the javadoc is what surfaces in IDE completion, the endpoint DSL builders, Camel JBang and Karavan tooling, and Spring Boot metadata, where the prose page is not visible at all. ### Other descriptions improved in the same pass These restated the option name without saying what the value controls: | Option | Added | |---|---| | `apexUrl` | It is a path relative to `/services/apexrest/`, not a URL, and can be given as the option, in the endpoint path as `apexCall/MyApexClass/`, or via `CamelSalesforceApexUrl` | | `jobId` | Which operations need it, and that it covers Bulk API v1 and 2.0 | | `batchId` | Bulk API v1 only; `BulkApiV2Processor` never reads it | | `resultId` | Used only by `getQueryResult`, sourced from `getQueryResultIds` | | `pubSubHost` / `pubSubPort` | gRPC transport and the operations that use them | Plus 15 Streaming API and Change Data Capture headers that followed a bare `"The <name>."` template. Most map to fields of the Salesforce `ChangeEventHeader`. Worth noting: `CamelSalesforceEventType` carries two different values. For change and platform events it is the last segment of the subscribed channel (`StreamingApiConsumer:181,225`); for PushTopic messages it is the Salesforce event type (`:254`). The description now covers both. ### Scope and testing Documentation only. Every changed line is javadoc or `@Metadata` text, so there is no behaviour change and no test is applicable. Descriptions were derived by reading the call sites rather than from the option names, and claims that could not be verified in code (Salesforce id formats, an exhaustive list of Apex verbs) were deliberately left out. The regenerated `salesforce.json` is included for both the component and the catalog, as is the convention for metadata changes. --- _Generated by Claude Code on behalf of @stn1slv_ -- 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]
