oscerd opened a new pull request, #25742: URL: https://github.com/apache/camel/pull/25742
Fixes [CAMEL-24477](https://issues.apache.org/jira/browse/CAMEL-24477). ## The CXF consumer describes route failures in the SOAP fault `CxfConsumer.checkFailure()` takes whatever is on `Exchange.getException()` and builds a CXF `Fault` from it, so the exception's message becomes the SOAP `faultstring` — and its class name does, when it has no message: ```java private static void buildFaultFromThrowable(Throwable t) { Fault fault = new Fault(t); if (fault.getMessage() == null) { fault.setMessage(t.getClass().getSimpleName()); } ``` Measured against the unfixed code, a client of a failing `cxf:` route receives: ``` jakarta.xml.ws.soap.SOAPFaultException: the-internal-detail-a-caller-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-cxf` has no equivalent. ## The change, and why it is narrower than the other consumers A `muteException` consumer option on `CxfEndpoint`, defaulting to `true`. **Unlike knative/mina, it cannot apply to every fault** — for a SOAP service, some faults *are* the contract. Muting those would break every client written against the WSDL rather than protect anything. So muting applies **only to an undeclared failure**: something on `Exchange.getException()` whose class carries no `@WebFault` annotation. These are all still returned in full: | Deliberate fault | Why it is preserved | |---|---| | a CXF `Fault` / `SoapFault` thrown by the route | already a fault object the route built | | an exception annotated `@WebFault` | declared in the WSDL; clients are generated against it | | a `Throwable` or `<soap:Fault>` `CxfPayload` set as the message **body** | the documented "SOAP faults as message body" path, kept for backwards compatibility | `checkFailure` now separates the exception path from the body path to make that distinction, which also let `extractThrowable` go — it existed only to merge the two. The muted stand-in has its stack trace cleared, since CXF can be configured to put the stack trace in the fault detail. ## Behaviour change worth a reviewer's eye Muting covers **framework** failures too, not just route exceptions. A `continuationTimeout` expiry previously returned `The OUT message was not received within: 5000 millis.` and now returns the generic fault. `CxfConsumerContinuationTimeoutTest` asserts that message, so it now sets `muteException=false` — the same migration a deployment relying on that diagnostic performs. The upgrade guide calls this out specifically. I kept it muted for consistency with the rest of the family, but this is the one place where the default costs real diagnostic signal — happy to special-case timeouts if the project would rather. ## Testing `CxfConsumerMuteExceptionTest` covers all four behaviours: * an undeclared failure is not described to the caller — **verified RED against unfixed code**, with `SOAPFaultException: the-internal-detail-a-caller-must-not-see` as the actual value; * `muteException=false` describes it as before; * **a declared `@WebFault` (`PingMeFault`) is still returned in full while muting is on** — the carve-out that makes the default safe; * the option defaults to `true`. Cross-checks that the carve-out is correctly scoped rather than inert: `CxfCustomizedExceptionTest`, `CxfConsumerFaultTest`, `CxfConsumerPayloadFaultTest` and `JaxWsWebFaultAnnotationToFaultTest` all pass unchanged — they throw `SoapFault`/`@WebFault`, which take the preserved branches. `camel-cxf-soap` 166/166 (2 pre-existing skips) and a full `mvn clean install -DskipTests` across the reactor. `camel-cxf-soap` did not declare `assertj-core`; added with `test` scope. ## Scope Third of four consumers split out of CAMEL-24428 (rescoped to `camel-knative`, [#25685](https://github.com/apache/camel/pull/25685)). Siblings: [CAMEL-24476](https://issues.apache.org/jira/browse/CAMEL-24476) (mina, built) and [CAMEL-24478](https://issues.apache.org/jira/browse/CAMEL-24478) (grpc, remaining). _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]
