Issue with jakarta.xml.ws.Endpoint.publish() in qcxf 2.7 (netty vs. vert.x)

[famod]

Hi @ppalaga (and others),

basically for years we had in my Quarkus project the usual quarkus-cxf dependencies (and the the BOM import) and a little further down in the respective pom.xml we had:

        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http-netty-server</artifactId>
            <scope>test</scope>
        </dependency>

This allows us to provide mock endpoints for our test like so:

public class SomeMockWSTestResource implements QuarkusTestResourceLifecycleManager {

        private static final SomePortType MOCK = mock(SomePortType.class);
        private static final String CLIENT_ENDPOINT_URL = "http://localhost:9000/ws/";

        @Override
        public Map<String, String> start() {
            Endpoint.publish(CLIENT_ENDPOINT_URL, MOCK));
            // ...
        }
        / ...
}

Endpoint.publish() was picking up org.apache.cxf.transport.http.netty.server.NettyHttpDestination and all was good.

With qcxf 2.7 though, the port in URL is not respected anymore and so our tests fail. We (better to say @mickroll) noticed that now io.quarkiverse.cxf.transport.VertxDestination is being picked up which doesn't have the engine.addServant(url, ...) call in activate.
Now, if we place cxf-rt-transports-http-netty-server before quarkus-cxf in the pom.xml (and thus on the classpath before it as well) the problem goes away.

Does that ring a bell? Is there a change since qcxf 2.6.1 that could explain this?

Thanks!

[ppalaga]

Yes, we changed the VertxDestination quite substantially to be able to support WS-RM. Could you perhaps somehow try to add the addServant call back and see whether everything still works?

[famod]

@ppalaga I don't see a quick way to adapt what's being done here https://github.com/apache/cxf/blob/cxf-4.0.3/rt/transports/http-netty/netty-server/src/main/java/org/apache/cxf/transport/http/netty/server/NettyHttpDestination.java#L134-L135 to VertxDestination: addServant is called on NettyHttpServerEngine which implements extorg.apache.cxf.transport.http.netty.server.ServerEngine and I don't see anything comparable in VertxDestination.

[ppalaga]

Your old way of getting a service endpoint served by a mock was indeed very elegant. I wonder whether we could somehow support this without NettyHttpServerEngine. The easiest way how we could make it possible that comes to my mind is to:

1. Allow #namedBean in addition to fully qualified class names in quarkus.cxf.endpoint."/mock".implementor. A piece of config like the following would have to exist in src/test/resources/application.properties :

quarkus.cxf.endpoint."/mock".implementor = #myMockedEndpoint

2. For now users would have to have a bean producer method annotated with something like @ApplicationScoped @Named("myMockedEndpoint") in their tests that returns the mock.
3. Later, we could perhaps come up with some sort of an annotation to simplify setting it up.

If you'd like to give this a try, it should be enough to change the following line

quarkus-cxf/extensions/core/runtime/src/main/java/io/quarkiverse/cxf/transport/CxfHandler.java

Line 112 in cfffe21

Object instanceService = CXFRuntimeUtils.getInstance(endpointType, false);

to

Object instanceService = CXFRuntimeUtils.getInstance(endpointType, true);

[famod]

Thanks @ppalaga, I'll try it once I find some time for it.

A few notes though:

A piece of config like the following would have to exist in src/test/resources/application.properties

I think in my case I'd still use a QuarkusTestResourceLifecycleManager (activated via a QuarkusTestProfile) to set that property, so that I can apply this "feature" to only a subset of tests in a module.

Also, as a startup optimization, I have the following in src/test/resources/application.yaml:

quarkus:
  http:
    # vertx-http is on the classpath, but we don't need a http server in this module
    host-enabled: false

I suppose this would have to go?

TBH, without much more simplification by qcxf I would keep my current solution.

[ppalaga]

I am thinking of introducing an annotation that would make the whole a lot simpler. Something like

@Produce
@CxfPath("/mock")
MyService produceMyService() {
    return Mock.whatever();
}

WDYT?

[ppalaga]

The question is how much of the current endpoint configuartion should be available through this new annotation(s).