Guillaume Nodet created CXF-9204:
------------------------------------
Summary: FailoverFeature NPE in ClientImpl.onMessage with Undertow
2.4.0.RC1
Key: CXF-9204
URL: https://issues.apache.org/jira/browse/CXF-9204
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 4.1.2
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
When using {{cxf-rt-transports-http-undertow}} with Undertow 2.4.0.RC1, the CXF
{{FailoverFeature}} fails with an NPE when using POJO
data format. The failover mechanism does not properly handle connection
failures because Undertow 2.4.0.RC1 passes a null
inbound message to the CXF client callback.
Stack trace:
{code}
WARNING: java.lang.NullPointerException: "inMsg" is null
at java.base/java.util.Objects.requireNonNull(Objects.java:259)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:515)
{code}
The test sends a request to a non-existent address, expecting CXF's
{{FailoverFeature}} (with {{RandomStrategy}}) to redirect to the real service.
With Undertow 2.4.0.RC1, the error propagation path differs from previous
Undertow versions — the transport returns a null message on connection error,
which {{ClientImpl.onMessage()}} does not guard against.
This only affects POJO data format mode. PAYLOAD mode works correctly.
Steps to reproduce:
1. Set up a CXF endpoint with {{FailoverFeature}} and {{RandomStrategy}}
2. Configure a non-existent primary address with a valid alternate address
3. Use {{dataFormat=POJO}}
4. Send a request — expect failover to the alternate address
5. Instead, {{SoapFault: ConnectException}} is thrown
Workaround: Use {{dataFormat=PAYLOAD}} instead of {{dataFormat=POJO}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
