Camel Quarkus CXF Extension

[javaduke]

This PR adds Camel Quarkus CXF Extension, addressing the issue #764 . Both SOAP client and SOAP server supported, in JVM and native modes.

[jamesnetherton]

Not sure if these should be direct dependencies of the extension or not.

I guess they're just here for convenience so that if somebody wants to use them, they are automatically available. If that's the case, I think it'd be better moving them to the BOM, so that folks can add them manually to their project if required.

[javaduke]

Well, you can't really use cxf without a transport, so I'm inclined to leave it here, but if you insist, I can move it back to the BOM, it's no big deal really.

[jamesnetherton]

Not so much the transport. But this stuff:

        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-ws-rm</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-ws-addr</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-ws-security</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-ws-policy</artifactId>
        </dependency>

Presumably ws-security is not strictly required in every app?

[javaduke]

Oh, I see, sure, I can move it out as well.

[jamesnetherton]

This is for the WS server part, right?

If so, similar to my previous comment, I don't think this should be a dependency of the extension by default. So it should be moved to the BOM.

However, I do not want us to be supporting HTTP transports like Jetty. We should be integrating with the Quarkus Vert.x HTTP server.

[javaduke]

Correct, I can move it out. I agree that ideally we want to support Vert.x, but CXF doesn't provide transport implementation for it (and I'm not sure if they will). I can try to implement one, but it may take a while. So as an interim solution let's support it and I'll see what I can do about supporting other transports.

[javaduke]

I created a ticket here: https://issues.apache.org/jira/browse/CXF-8742
Please feel free to add your comments and/or corrections.

[jamesnetherton]

To me it's mandatory that the endpoints are run on the Quarkus Vert.x HTTP server. Otherwise we're just making the app performance worse and exposing ourselves to more CVEs.

AFAIK quarkiverse-cxf has already solved this problem.

[javaduke]

Yes, I tried it, for some reason CXF does not recognize the VertxDestinationFactory that is provided by quarkiverse-cxf. I'll keep investigating.

[zhfeng]

So maybe we can consider to leverage on quarkus-cxf.

[javaduke]

I'm trying to figure out how it's done there, but it seems like we'd have to rewrite Camel CXF completely, because there seems to be no way to pass the factories defined in the quarkus-cxf to Camel...

[javaduke]

OK, I think I know what's going on - currently Camel does not allow creating custom JaxWsServerFactroryBean: https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-soap/src/main/java/org/apache/camel/component/cxf/jaxws/CxfEndpoint.java#L683
This means that destination factories are initialized in the Camel CXF code, and apparently custom destination factories are ignored. Not sure if there's any way around it, apparently not...

[zhfeng]

@ffang can you take a look?

[javaduke]

OK, I think we're done - this PR now uses Quarkus CXF for SOAP services and WS-Security, all tests pass correctly.

[javaduke]

Apparently the Quarkus CXF uses a newer version of the xmlsec which causes test failures in the xmlsecurity extension, but I have a fix for that. See https://santuario.apache.org/faq.html 4. Secure Validation

[javaduke]

Any updates? Comments?

[jamesnetherton]

Any updates? Comments?

We should probably wait until Camel 3.18.1 is available (hopefully next week) because it fixes the dependency that was not properly test scoped:

https://github.com/apache/camel/blob/main/components/camel-cxf/camel-cxf-common/pom.xml#L104

So we wont need to pull in a bunch of redundant dependencies.

[jamesnetherton]

Thinking also we should have a 'code first' test for the consumer. Right now we're just feeding the endpoint a WSDL file. Would be good to also test a JAX-WS annotated service interface.

[javaduke]

Sure, I can work on code first test, although I see it a bit redundant, since the service interface is generated from the WSDL by the cxf-codegen-plugin during the build and then configured in the endpoint: camel.beans.soapServiceEndpoint.serviceClass=com.helloworld.service.HelloPortType

[javaduke]

OK, code-first test added

[ppalaga]

Very nice @javaduke! Some nitpicks inline which I can try to fix myself tomorrow. Thank you very much for your endurance!

[ppalaga]

Aren't these a bit overlapping with what we collect bellow via getAllKnownImplementors() ?
I mean AbstractFeature implements org.apache.cxf.feature.Feature,
AbstractPhaseInterceptor implements org.apache.cxf.phase.PhaseInterceptor, etc.
so each subclass if the given abstract class will implement the interface and will inevitably be caught by the getAllKnownImplementors() query, no?

[ppalaga]

Suggested change

	<camel.quarkus.jvmSince>2.11.0</camel.quarkus.jvmSince>
	<camel.quarkus.nativeSince>2.11.0</camel.quarkus.nativeSince>
	<camel.quarkus.jvmSince>2.12.0</camel.quarkus.jvmSince>
	<camel.quarkus.nativeSince>2.12.0</camel.quarkus.nativeSince>

A bit too late for 2.11.0

[zbendhiba]

Many thanks @javaduke for this great work! Happy to find out this has been merged.