oscerd opened a new pull request, #25741: URL: https://github.com/apache/camel/pull/25741
Fixes [CAMEL-24476](https://issues.apache.org/jira/browse/CAMEL-24476). ## The Mina consumer writes the route's exception to the peer When an exchange fails and `transferExchange` is off, `MinaConsumer` writes `exchange.getException()` — the `Throwable` itself — straight back over the socket: ```java boolean failed = exchange.isFailed(); if (failed && !getEndpoint().getConfiguration().isTransferExchange()) { if (exchange.getException() != null) { response = exchange.getException(); } ... } if (response != null) { MinaHelper.writeBody(session, response, exchange, configuration.getWriteTimeout()); } ``` With a textline codec the peer gets its class and message; with the object codec it gets the serialised exception, cause chain and stack trace included. Measured against the unfixed code, a peer of a failing `from("mina:tcp://...?textline=true&sync=true")` route reads back: ``` java.lang.IllegalStateException: the-internal-detail-a-peer-must-not-see ``` [CAMEL-23651](https://issues.apache.org/jira/browse/CAMEL-23651) aligned the HTTP consumers on a `muteException` option defaulting to `true`. `camel-mina` has no equivalent. ## The change A `muteException` consumer option on `MinaConfiguration`, defaulting to `true`. **A reply is still written** — this is the part worth a reviewer's eye. Suppressing the write entirely would set `disconnect = true` and leave a synchronous peer to time out rather than learn the request failed, so the muted case writes a stand-in: a `java.lang.Exception` with a fixed message. It stays a `Throwable`, so a peer using the object codec still deserialises what it expects, but it carries neither the class nor the message of the route's exception. Its own stack trace is cleared (`setStackTrace(new StackTraceElement[0])`) — left in place, the object codec would serialise *this consumer's* frames to the peer instead, which is the same disclosure one level down. `transferExchange=true` is untouched: that option serialises the whole Exchange by design and is already marked `security = "insecure:serialization"`. ## Testing * New `MinaMuteExceptionTest` — asserts the reply carries neither the detail nor the exception class, **and that a reply is still sent** (not a dropped connection). Verified RED against unfixed code, with `java.lang.IllegalStateException: the-internal-detail-a-peer-must-not-see` as the actual value. A second test covers `muteException=false`. * Three existing tests asserted the old behaviour — `MinaTcpWithInOutUsingPlainSocketTest`, `MinaTcpWithIoOutProcessorExceptionTest`, `MinaTcpLineDelimiterUsingPlainSocketTest` each expect `java.lang.IllegalArgumentException: Forced exception` at the peer. They now set `muteException=false`, which is the same migration an affected deployment performs, and keeps their original intent (the exception does round-trip when asked for). * `camel-mina` did not declare `assertj-core`; added with `test` scope. `camel-mina` 103/103 (4 pre-existing skips) and a full `mvn clean install -DskipTests` across the reactor. ## Scope One of four consumers split out of CAMEL-24428, which has been rescoped to `camel-knative` ([#25685](https://github.com/apache/camel/pull/25685)). Siblings: [CAMEL-24477](https://issues.apache.org/jira/browse/CAMEL-24477) (cxf) and [CAMEL-24478](https://issues.apache.org/jira/browse/CAMEL-24478) (grpc). _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]
