allthingssecurity opened a new pull request, #28032:
URL: https://github.com/apache/camel/pull/28032

   # Description
   
   [CAMEL-25724](https://issues.apache.org/jira/browse/CAMEL-25724)
   
   The `preserveMessageQos` option documents that a QoS header that is not 
provided (`JMSPriority`, `JMSDeliveryMode`, `JMSExpiration`) falls back to the 
value of the endpoint. `CamelJmsTemplate.doSend` does that for the priority, 
but takes the time to live only from the `JMSExpiration` of the message. A 
message without expiration (header missing, or 0) is sent with time to live 0, 
which means "never expires":
   
   - InOnly: `jms:queue:orders?preserveMessageQos=true&timeToLive=60000` sends 
messages that never expire.
   - InOut: the `requestTimeout` (default 20 s) that Camel sets as time to live 
of the request is lost, so a request whose caller already timed out stays on 
the queue and is processed later.
   
   Change: when the message has no expiration, `doSend` uses the time to live 
of the template, which is the endpoint `timeToLive` (InOnly), 
`timeToLive`/`requestTimeout` (InOut), and 0 when none is configured or 
`disableTimeToLive=true`. A message with an expiration is sent as before.
   
   What users can notice: with `preserveMessageQos=true`, messages without 
expiration now expire after the configured time to live, and request/reply 
requests after the request timeout, as they do without the option. A message 
bridged from another JMS endpoint with expiration 0 also gets the endpoint 
value, because the producer cannot tell a 0 header from a missing one (the 
priority has the same limit). `disableTimeToLive=true` keeps the old behaviour. 
A note is added to the 4.24 upgrade guide.
   
   Tests:
   - New `JmsPreserveMessageQosTimeToLiveTest` (6 tests): the time to live 
given to a mocked `MessageProducer` for the InOnly and the InOut template, and 
a route on the embedded Artemis broker that checks the `JMSExpiration` of the 
received message.
   - Without the change: 3 of the 6 fail (InOnly `timeToLive=5000`: 0 sent; 
InOut default request timeout: 0 sent instead of 20000; broker: `JMSExpiration 
was 0`). The other 3 pass on main too and are kept as guards for what must not 
change: a message with an expiration keeps its remaining time, 
`disableTimeToLive=true` sends 0, an endpoint without `timeToLive` sends 0.
   - With the change the camel-jms tests pass: 452 + 16 + 6 run in the three 
surefire executions, 0 failures, 0 errors, 11 skipped.
   
   What is not changed: the delivery mode and the priority handling of 
`preserveMessageQos`, the `explicitQosEnabled` path, and camel-sjms, whose 
`SjmsTemplate.send` has the same gap (follow-up).
   
   What was not run: the full root build.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked 
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for 
the change (usually before you start working on it): 
[CAMEL-25724](https://issues.apache.org/jira/browse/CAMEL-25724).
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   - [ ] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
     (I built and tested camel-jms, including the formatter and import-sort 
plugins. I did not run the full root build.)
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper 
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR 
description identifies the AI tool used.
     This PR was prepared with Claude Code (Claude Opus 5.5). The commit 
carries a `Co-Authored-By` trailer.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 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]

Reply via email to