oscerd opened a new pull request, #3012:
URL: https://github.com/apache/camel-kamelets/pull/3012
Fixes #2263. Also covers the first half of #1546, which asks for the same
thing — I have left that one open and commented there rather than closing it,
because its second question about keystore authentication is separate and still
unanswered.
## The API has been there; the catalog had not caught up
`camel-salesforce` in 4.22 carries both Pub/Sub operations:
```
operationName enum -> [..., 'subscribe', 'pubSubSubscribe', 'pubSubPublish']
```
along with `pubSubBatchSize`, `pubSubDeserializeType`, `pubSubPojoClass`,
`pubSubReplayId`, `replayPreset`, and host/port options. The catalog only had
`salesforce-source`, which uses the **older streaming API** (`subscribe`,
topics, `notifyForOperation*`). This adds a source for the gRPC one.
I did the source rather than both halves: #2263 asks about consuming, and a
`pubSubPublish` sink is a clean follow-up rather than something to bundle here.
## One default deliberately differs from the component
`deserializeType` defaults to **JSON**, where the component defaults to
**AVRO**.
A Kamelet emits to `kamelet:sink`, and AVRO puts binary on the body that the
next step has to decode before it is useful. JSON is usable as-is, which is the
point of a Kamelet. All five values remain available, and the property
description states plainly that AVRO is the component's own default so nobody
is surprised.
## A runtime caveat worth knowing about
Verifying this turned up something users will hit. Under Camel JBang the
resolved `protobuf-java` is older than the generated gRPC stubs in
`camel-salesforce` expect, and the route dies during class loading:
```
java.lang.NoClassDefFoundError:
com/google/protobuf/RuntimeVersion$RuntimeDomain
```
That is before any endpoint is built, so it looks nothing like a
configuration problem. Adding protobuf explicitly fixes it:
```
camel run route.yaml --dep=com.google.protobuf:protobuf-java:4.35.1
```
I put this in the Kamelet description rather than leaving it to be
rediscovered.
**I did not add it to `spec.dependencies`.** It would work, and protobuf is
BSD-3 so the licence is fine, but every pinned `mvn:` version in this catalog
is managed from the root pom by the `UpdateKamelets` step —
`artemis-jakarta-client-all` is the model. Hardcoding `4.35.1` here would drift
from Camel the first time it moves. Wiring a managed `protobuf-version`
property is the correct fix and is a maintainer decision about version
coupling, so I have flagged it rather than made it. Say the word and I will do
it properly.
## Verification
`script/validator` reports no errors, `script/generator` adds the `nav.adoc`
entry, `mvn clean install` passes **with tests** from the repository root.
With protobuf pinned, the Kamelet reaches a real login attempt and fails
only on the deliberately invalid host:
```
Failed to start component local-salesforce-pubsub-1 because of
SalesforceException: Unexpected login error: login.salesforce.invalid
Caused by: java.net.UnknownHostException
```
Every parameter binds and the gRPC path is exercised — the failure is the
network, not the configuration.
**No Citrus test**: this needs a real Salesforce org, which no emulator
provides. Ships `Preview` without `kamelet.verified=true`.
---
_Claude Code on behalf of Andrea Cosentino_
--
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]
