[
https://issues.apache.org/jira/browse/CXF-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-9204.
-------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 4.2.1
>
>
> 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)
