davsclaus opened a new pull request, #29737: URL: https://github.com/apache/camel/pull/29737
[CAMEL-26506](https://issues.apache.org/jira/browse/CAMEL-26506): two findings from CAMEL-26152 (#28925). ## 1. transferException: the reply and a rollback (camel-jms, camel-sjms, camel-sjms2) With `transferException=true` and a failed exchange, the listener callback sends the exception as the reply and decides not to rethrow. But `onMessage` then looked the failure up again with `exchange.getException(RuntimeCamelException.class)`, which walks the causes. When the exception was a `RuntimeCamelException`, or had one as a cause, it was rethrown anyway: - transacted: the session rolled back the request **and the reply** (the caller timed out), and the request was redelivered; - not transacted: the listener container reported an error for a message that was handled. An `IllegalArgumentException` did not do this, so the outcome depended on the type of the exception. Now the callback keeps the failure it decided on, and `onMessage` rethrows exactly that. A reply that cannot be sent still fails the message, as before (CAMEL-26152, `InOutConsumerReplyFailureTest`). ## 2. camel-sjms: a received StreamMessage is an InputStream, as in camel-jms The sjms consumer gave the `jakarta.jms.StreamMessage` itself as the body, although sjms can send one with `jmsMessageType=Stream`. `JmsBinding` now maps it to a `StreamMessageInputStream`, as camel-jms does (`mapJmsMessage=false` still gives the JMS message). The body-type metadata of sjms and sjms2 (`consumerOut`: `stream` instead of `pojo`), their docs and the catalog copies are updated. While making the sjms copy, two bugs in camel-jms's `StreamMessageInputStream` showed up, fixed in both: - `read(byte[], off, len)` ignored `off` and `len` and always wrote at index 0. `readAllBytes()` and an `InputStreamReader` (a multi-byte character across reads) read at an offset, so they got corrupt data. - `read()` called `readByte()`, which a `byte[]` field (what both producers write) does not allow, so it threw. ## Upgrade guide (4.24) Two notes: the transferException outcome no longer depends on the exception type, and the sjms/sjms2 consumer body of a `StreamMessage` is now an `InputStream`. ## Tests - `JmsTransferExceptionTransactedTest` (camel-jms) and `TransferExceptionTransactedTest` (camel-sjms): a transacted consumer throws a `RuntimeCamelException`, or an exception caused by one. The caller gets the exception, and the request is processed once. Both fail without the fix (the caller times out). - `StreamMessageConsumerTest` (camel-sjms): 300 KB sent with `jmsMessageType=Stream` (several fields) arrives as an `InputStream` with the same bytes, read with `readAllBytes`. Fails without the fix. - `StreamMessageInputStreamTest` (both modules): `readAllBytes`, one byte at a time, a buffer smaller than a field, UTF-8 text across fields, and `reset`, over a `StreamMessage` that follows the `readBytes` contract. The camel-jms one fails on the old class. - camel-sjms (213) and camel-sjms2 (28) pass; camel-jms: the transfer, transacted, InOut, reply, stream and exception tests (270) pass. _Claude Code on behalf of davsclaus_ 🤖 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]
