Stanislav Deviatov created CAMEL-24340:
------------------------------------------
Summary: camel-salesforce: apexMethod is documented as an Apex
method name but is used as the HTTP verb
Key: CAMEL-24340
URL: https://issues.apache.org/jira/browse/CAMEL-24340
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Reporter: Stanislav Deviatov
Fix For: 4.22.0
The {{apexMethod}} option is documented as "APEX method name", but the
component uses the value verbatim as the HTTP verb of the Apex REST call.
h3. Trace
* {{AbstractRestProcessor:637}} reads the option, and defaults it to {{GET}} at
{{:640}} with the log message "Using HTTP GET method by default for APEX REST
call".
* {{:653}} passes it as the first argument to {{restClient.apexCall(...)}}.
* {{RestClient:243}} declares that parameter as {{String httpMethod}}, with the
javadoc "HTTP method to execute".
* {{DefaultRestClient:499}} forwards it to {{getRequest(httpMethod, ...)}}, and
{{AbstractClientBase:169-171}} passes it straight into Jetty's
{{HttpRequest.method(String)}}.
There is no validation, enum, or lookup at any step.
{{DefaultRestClient:503-512}} then switches on {{request.getMethod()}} to
decide whether to attach a body, which only makes sense for a verb.
h3. Impact
A user who follows the documentation and sets {{apexMethod}} to their actual
Apex method name, for example {{getMerchandise}}, causes Camel to issue
{{GETMERCHANDISE /services/apexrest/...}}, which fails.
The wording dates from CAMEL-8772 (2015) and has been propagated mechanically
ever since. It has never been deliberately reviewed.
h3. Anticipated objection
The hand-written Apex REST table already describes it correctly as "The HTTP
method (e.g. GET, POST) to use", so this may look cosmetic. Two reasons it is
not:
* The generated options table is included in the same page at
{{salesforce-component.adoc:58-60}}, roughly 175 lines above the hand-written
table at line 233. Both render in one view, so the page contradicts itself.
* The javadoc text is what surfaces in IDE completion, the endpoint DSL
builders ({{SalesforceEndpointBuilderFactory}}), Camel JBang and Karavan
tooling, and Spring Boot metadata. In those consumers the prose page is not
visible at all, and the only text a user sees is "APEX method name".
h3. Other option descriptions improved in the same change
These restate the option name without saying what the value controls:
* {{apexUrl}} - described as "APEX method URL", but it is a path relative to
{{/services/apexrest/}}. The value can be supplied as this option, in the
endpoint path as {{apexCall/MyApexClass/}}, or via the
{{CamelSalesforceApexUrl}} header.
* {{jobId}} - does not say which operations need it, or that it applies to both
Bulk API v1 and Bulk API 2.0.
* {{batchId}} - does not say it is Bulk API v1 only. {{BulkApiV2Processor}}
never reads it.
* {{resultId}} - does not say it is used only by {{getQueryResult}}, or that
the value comes from {{getQueryResultIds}}.
* {{pubSubHost}} / {{pubSubPort}} - accurate but minimal; no mention of the
gRPC transport or which operations use them.
* 15 Streaming API and Change Data Capture headers follow a bare "The <name>."
template. For example {{CamelSalesforceChangeType}} is documented as "The
change type." Most map to fields of the Salesforce {{ChangeEventHeader}}.
Note that {{CamelSalesforceEventType}} carries two different values: for change
and platform events it is the last segment of the subscribed channel
({{StreamingApiConsumer:181,225}}), while for PushTopic messages it is the
Salesforce event type ({{:254}}).
h3. Scope
Documentation only. The change edits javadoc and {{@Metadata}} descriptions and
regenerates the component metadata. No behaviour changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
