Croway commented on PR #29489: URL: https://github.com/apache/camel/pull/29489#issuecomment-6765767305
I filed four follow-ups for what this PR leaves out: - [CAMEL-26808](https://issues.apache.org/jira/browse/CAMEL-26808): device-side consumer (cloud-to-device messages, direct methods, desired properties) - [CAMEL-26809](https://issues.apache.org/jira/browse/CAMEL-26809): service-side operations - [CAMEL-26810](https://issues.apache.org/jira/browse/CAMEL-26810): message properties - [CAMEL-26811](https://issues.apache.org/jira/browse/CAMEL-26811): X.509 authentication None of them should block this PR. Three points do affect it: 1. **Scope of the scheme.** `azure-iothub:deviceId` with a device connection string makes this a device-side component, while CAMEL-22624 asked for the service SDK. Can we decide before 4.24 ships whether the service-side operations (CAMEL-26809) go here behind an `operation` option or get their own scheme? Changing the URI after a release needs an upgrade-guide entry. 2. **Pool design.** The changes already requested to the pool (component scope, leases, a key taken from the device identity: davsclaus's points 3 and 7, gnodet-bot's F4) are also what a consumer will need. IoT Hub drops a device's connection when a second one opens for the same device id (error 400027), so a producer and a consumer for the same device have to share one `DeviceClient`. 3. **Body conversion.** `TelemetryDeliveryStrategy.toBytes` accepts only `byte[]` and `String`. I ran `IoTHubProducer.process` on 4701e30fe143 with a mocked `DeviceClient`: ``` InputStream body -> Telemetry delivery expects a byte[] or String body but was: java.io.ByteArrayInputStream InputStreamCache body -> Telemetry delivery expects a byte[] or String body but was: org.apache.camel.converter.stream.InputStreamCache ``` Stream caching is on by default, so a body that arrives as a stream usually reaches the producer as an `InputStreamCache`. Converting the body in `buildContext` with `getMandatoryBody(byte[].class)` for `TELEMETRY`/`BOTH` would handle both cases. Docs suggestion: the component page could link to `camel-azure-eventhubs` for reading device-to-cloud telemetry from the built-in Event Hubs-compatible endpoint. That is the consumer most users will look for first. _Claude Code on behalf of Croway_ -- 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]
