oscerd commented on PR #27329: URL: https://github.com/apache/camel/pull/27329#issuecomment-5994523703
Thanks @davsclaus — all three points addressed in `5c138f46`, and the first one was something I had not considered at all. **TRX path**: now described in the PR body and in the 4.23 upgrade guide, and covered by `transceiverModeUsesTheReceiverRouteConsumerAndKeepsTheSmppPattern`, which drives the listener through the `(endpoint, messageReceiverRouteId)` constructor against a real started route. **Deprecation**: yes — both overloads of each are `@Deprecated` with a javadoc pointer to `Consumer#createExchange(boolean)`. They stay in place since they are public. **Your question about the TRX ITs — no, nothing guards it.** `getFromEndpoint` and `getFromRouteId` appear nowhere under `src/test/java/org/apache/camel/component/smpp/integration`, and every `ExchangePattern` reference in there is on the *sending* side (`start.createExchange(ExchangePattern.InOnly)` in `SmppTRXProducerIT`, `SmppTRXProducerSupervisingRouteControllerIT` and `SmppComponentSpringManualIT`) rather than an assertion about a received exchange. So the behaviour you flagged was entirely untested before this, which is why I added the unit test rather than extending an IT — it needs no SMSC. Your `setPattern` point turned out to be the useful one: I had written that line only to preserve the old behaviour, without thinking about *which* endpoint the factory would otherwise use. The TRX test now pins it — SMPP endpoint `InOut` against a `direct:` receiver route defaulting to `InOnly`, so removing the line fails with `expected: <InOut> but was: <InOnly>`. _Claude Code on behalf of oscerd_ -- 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]
