oscerd opened a new pull request, #26490: URL: https://github.com/apache/camel/pull/26490
Backport of #26427 (CAMEL-24729) to `camel-4.22.x`, as flagged by the `port/camel-4.22.x` label. An expiry needs both an amount and the unit it is expressed in, and the producer requires both headers before applying one. With only one of a pair set the condition was false and the write fell through to the plain `cache.put(key, value)` overload, so a route setting `CamelInfinispanLifespanTime` without `CamelInfinispanTimeUnit` stored an entry that **never expires**, with nothing in the log to say the expiry had been dropped. Same for the max-idle pair, across the eight operations that can carry an expiry, and neither value has an endpoint option to fall back on. Each pair is now reported at WARN the first time a producer sees it — a route that gets this wrong gets it wrong for every message, so this does not repeat per exchange. The entry is still stored and a message carrying neither header stays silent. ### Not a byte-identical cherry-pick — one mechanical addition The diff against #26427 is not empty, so flagging it rather than letting a reviewer find it: this adds the `LOG` field and its two `org.slf4j` imports to `InfinispanProducer`. On `main` that logger is already there, because the QUERY warning from CAMEL-24623 was later lifted into the shared producer. On this branch that dedup never happened — each subclass still keeps its own `warnNoQueryBuilder` and its own logger — so the shared producer had none to reuse and the cherry-pick would not compile without it. No behaviour differs from `main` beyond that. ### Verification `mvn clean install -DskipITs` on `components/camel-infinispan` is green on this branch — 94 embedded tests and 13 remote. The warning was checked against the log rather than assumed green: a clean run writes exactly **4** lines to `target/camel-infinispan-test.log`, one per pair per producer instance, from a test that calls each check twice — the same count observed on `main`. Without the once-per-producer guard the same test would write 6. Built the whole `camel-infinispan` aggregate rather than the single module, so `camel-infinispan-common` is compiled in-reactor: a module-scoped build resolves it from `~/.m2`, where a concurrent build of the same SNAPSHOT can leave a jar without these changes. --- _Claude Code on behalf of oscerd_ 🤖 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]
