davsclaus opened a new pull request, #28925: URL: https://github.com/apache/camel/pull/28925
Fixes [CAMEL-26152](https://issues.apache.org/jira/browse/CAMEL-26152). `camel-sjms2` inherits this code, so it gets both fixes. ### 1. An InOut reply that cannot be sent was dropped silently **What was wrong:** when the reply could not be sent (for example an `Integer` reply without `objectMessageEnabled`), `EndpointMessageListener.sendReply` caught the error and set a `CamelExchangeException` on the exchange. `onMessage` only rethrows a `RuntimeCamelException`, so the error was ignored: the request was committed or acknowledged, no reply was sent and nothing was logged. **What changed:** after `sendReply`, the callback checks for an exception that `sendReply` set, and rethrows it like a route failure. This is what camel-jms does (its `sendReply` lets the exception through to the listener container). So: - `transacted=true`: the request is rolled back and the broker delivers it again. - `CLIENT_ACKNOWLEDGE`: the session is recovered. - `AUTO_ACKNOWLEDGE`: the message stays acknowledged (as for a failed route), but the error is now logged as a WARN. - async consumer: the exception goes to the consumer's exception handler. The check skips the exception that the route itself failed with (the `transferException` case), so only a reply send failure is rethrown. ### 2. `jmsMessageType=Stream` failed with a NullPointerException **What was wrong:** `JmsBinding.createJmsMessageForType` had no `Stream` case and returned `null`. `createJmsMessage` then called `setJMSDeliveryMode` on `null`. **What changed:** a `Stream` case writes the body (converted to `InputStream`) to a `StreamMessage` in chunks, the same as camel-jms. A type that is not handled (`jmsMessageType=Message`) now fails with a `JMSException` that names the type, instead of returning `null`. The `Object` case got braces so its `message` variable does not clash. ### Tests - `InOutConsumerReplyFailureTest` (new): a transacted InOut consumer returns an `Integer`. Checks that the request is delivered again. Before the fix it was delivered once and committed. - `JmsMessageTypeTest`: `testJmsMessageTypeStream` sends with `jmsMessageType=Stream` and reads the `StreamMessage` bytes. `testJmsMessageTypeNotSupported` checks the `JMSException` for `jmsMessageType=Message`. Before the fix both failed with the `NullPointerException`. - All 3 new tests failed without the fix. Full module builds with `-Psourcecheck`: camel-sjms 189 tests + 4 ITs, camel-sjms2 28 tests, all pass. ### Docs and generated files - `sjms-component.adoc` and `sjms2-component.adoc`: a line on `jmsMessageType=Stream`, and a paragraph on what happens when the InOut consumer cannot send the reply. - The `consumerReply` `@BodyTypes` description of both endpoints said the reply "is dropped". It now says the incoming message fails. The component JSON and the catalog copies are regenerated. - Upgrade guide 4.24: a new `camel-sjms` entry, as a transacted consumer now redelivers such a request. ### Not changed: bug 3 (a body with no JMS message type is sent as an empty `Message` with a WARN) camel-jms has the same code and does the same thing, and the WARN text is a deliberate hint. Failing the exchange instead would change behaviour that users may rely on, and would make camel-sjms differ from camel-jms. I left it out and asked on the JIRA whether to change it in both components (with an upgrade-guide entry), in a follow-up. _Claude Code on behalf of Claus Ibsen (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]
