davsclaus opened a new pull request, #28987: URL: https://github.com/apache/camel/pull/28987
Fixes [CAMEL-26505](https://issues.apache.org/jira/browse/CAMEL-26505). Follow-up of CAMEL-26152 (#28925). ## What was wrong When the body could not be mapped to a JMS message type (for example a POJO that is not `Serializable` and has no type converter to `File` or `InputStream`), `JmsBinding.createJmsMessage` in camel-jms and in camel-sjms logged a WARN (`Cannot determine specific JmsMessage type to use from body class. Will use generic JmsMessage. ...`) and sent an empty `jakarta.jms.Message`. The exchange succeeded and the body was lost. For an InOut consumer the same happened to the reply: the caller got a `null` body. ## What changed - `JmsBinding` in camel-jms and camel-sjms now throws a `jakarta.jms.MessageFormatException` for a non-null body that maps to no type. This is the exception the same method already throws when a body cannot be converted for a chosen type (Bytes, Object, Stream). The message names the body class and keeps the hint of the old WARN: implement `java.io.Serializable` (and enable `objectMessageEnabled`), set the `jmsMessageType` option, or marshal the body (for example to JSON or XML). - A `null` body is still sent as an empty `jakarta.jms.Message` (unchanged; `allowNullBody=false` still fails as before). - Producer: the exchange fails with the exception. - InOut reply sent by the consumer: the reply is not sent and the incoming message fails as when the route fails (rolled back when `transacted=true`). camel-jms already rethrew a failed reply from `onMessage`; camel-sjms does so since CAMEL-26152. - camel-amqp, camel-activemq, camel-activemq6 (extend camel-jms) and camel-sjms2 (extends camel-sjms) inherit the change. ## Why the WARN was there `git blame`: the WARN was added in 2009 for CAMEL-1749 ("Message body lost when message moved by exception clause", resolved *Not A Problem*). The user had a JAXB object as body and got an empty message; the commit says "Improved feedback from Camel when it uses a generic JMS message instead of specialized". So the WARN was diagnostic feedback for exactly this lost-body case, not a deliberate choice to keep sending empty messages. In 2010 it was limited to a non-null body. Failing the exchange matches how the `Object` case already fails when `objectMessageEnabled` is false. ## Tests - camel-jms: new `JmsUnmappableBodyTest`: a POJO body fails the producer with a `MessageFormatException` naming the class and hint, and nothing is received; a `null` body is still received; an InOut reply with a POJO body is not sent (requester times out) and the transacted request is redelivered. - camel-sjms: new `producer/UnmappableBodyTest` (producer fails and nothing is sent; `null` body sends a plain `Message`) and a new `testUnmappableReplyRollsBack` in `consumer/InOutConsumerReplyFailureTest` (POJO reply: requester times out, transacted request is redelivered). - The producer and reply tests fail without the fix (no exception thrown; the reply arrived with a `null` body) and pass with it. - No existing test relied on the old behaviour; none had to be changed. - Full suites: camel-jms (`clean install -Psourcecheck`), camel-sjms (`clean install -Psourcecheck`), camel-sjms2, camel-amqp and camel-activemq all pass. In camel-jms, `JmsInOutRoutingSlipTest` (String bodies only) flaked once while another suite ran in parallel and passed on the surefire rerun. ## Docs - `jms-component.adoc`: the mapping table gets a `null` row and a paragraph on bodies of other types (converted to `File`/`InputStream`, otherwise sending fails). - `sjms-component.adoc` and `sjms2-component.adoc`: the "Any other object" row no longer says a `Message` without body is sent with a WARN; it now says sending fails, and a row for objects that convert to `InputStream` is added (that path existed but was not in the table). - Catalog copies of the three pages updated. - Upgrade guide 4.24: one section for camel-jms and camel-sjms, next to the other jms/sjms entries. ## Not changed - No new option to restore the old behaviour: sending an empty message for a non-null body silently loses data. A route that relied on it can send a `null` body explicitly or force a type with `jmsMessageType`. - `@BodyTypes` of the endpoints only describe the consumer output and are unaffected. _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]
