NullPointerException: HttpClientPool in org.apache.cxf.Bus using VertxHttpClientHTTPConduitFactory

[famod]

I tried the now default VertxHttpClientHTTPConduitFactory (using URLConnectionHTTPConduitFactory currently) and my tests are failing with:

[...]
Caused by: java.lang.NullPointerException: HttpClientPool in org.apache.cxf.Bus
	at java.base/java.util.Objects.requireNonNull(Objects.java:259)
	at io.quarkiverse.cxf.HTTPConduitImpl$3.createConduit(HTTPConduitImpl.java:55)
	at io.quarkiverse.cxf.QuarkusHTTPConduitFactory.configure(QuarkusHTTPConduitFactory.java:74)
	at io.quarkiverse.cxf.QuarkusHTTPConduitFactory.createConduit(QuarkusHTTPConduitFactory.java:68)
	at org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:237)
	at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:226)
	at org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:233)
	at org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:144)
	at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:108)
	at org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:77)
	at org.apache.cxf.endpoint.ClientImpl.getConduit(ClientImpl.java:973)
	at de.someproject.SoapApiClientSupport.getConduit(TspSoapApiClientSupport.java:36)
	[...]

The conduit lookup looks like this:

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;

    @CXFClient
    private final MyPortType myPortType;

    public HTTPConduit getConduit() {
        return (HTTPConduit) ClientProxy.getClient(myPortType).getConduit();
    }

Any ideas?

[famod]

Hint: Debugger nevers stops in VertxWebClientRecorder so it's not called apparently.

[famod]

Turns out that it must have something to do with the test (dependency?) setup for those two affected maven modules because when those modules end up in my bigger Quarkus app (that is then operated as a container), the issue does not occur!

[ppalaga]

Couldn't it be an initialization order problem? From where is the client called in the failing test? Is it early at application starup by any chance?

Another option could be that you have two Bus instances in your test for some reason? What kind of test is it?

[ppalaga]

Anyway, registering the HttpClientPool instance on the Bus was motivated by my intention to eventually donate the VertxHttpClientConduit stuff to CXF - so I wanted to keep it independent of Quarkus as far as possible. I gave up on that in 3.16 and therefore we could actually get rid of VertxWebClientRecorder and rather rely on Arc.container().instance(HttpClientPool.class) in io.quarkiverse.cxf.HTTPConduitImpl$3.createConduit(HTTPConduitImpl.java:55)

[ppalaga]

@famod would you like to test this fix? #1598

[famod]

Couldn't it be an initialization order problem? From where is the client called in the failing test? Is it early at application starup by any chance?

Well, the issue pops up in a @PostConstruct method of a bean that is (indirectly) using myPortType.

Another option could be that you have two Bus instances in your test for some reason? What kind of test is it?

I don't think so. It's a @QuarkusTest (with a @TestProfile) and if fails if executed among other as well as alone.

[ppalaga]

Well, the issue pops up in a @PostConstruct method of a bean that is (indirectly) using myPortType.

That could explain it.