Generating Java Rest Client based on CXF

[peteryhwong]

As there is now a provision to generate Java CXF-specific Rest server stub (#1854), we would like to see codegen to support generation of Java CXF-specific Rest client. This is because we use CXF as our JAX-RS implementation and would like to leverage this implementation for our client libraries (specifically for inter-service interaction). The current client generator uses Jersey which causes conflict when being used in conjunction with CXF.

[wing328]

@peteryhwong the Java API client supports many HTTP libraries (e.g. Retrofit, Jersey2.x, etc). Please run java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar config-help -l java for a list of HTTP libraries support.

Ref: https://github.com/swagger-api/swagger-codegen#customizing-the-generator

[peteryhwong]

@wing328 thanks for this. If I understand correctly, the JavaClientCodeGen supports the following:

        <default> - HTTP client: Jersey client 1.18. JSON processing: Jackson 2.4.2
        jersey2 - HTTP client: Jersey client 2.6
        feign - HTTP client: Netflix Feign 8.1.1.  JSON processing: Jackson 2.6.3
        okhttp-gson - HTTP client: OkHttp 2.4.0. JSON processing: Gson 2.3.1
        retrofit - HTTP client: OkHttp 2.4.0. JSON processing: Gson 2.3.1 (Retrofit 1.9.0)
        retrofit2 - HTTP client: OkHttp 2.5.0. JSON processing: Gson 2.4 (Retrofit 2.0.0-beta2)

which do not include CXF client (http://cxf.apache.org/docs/jax-rs-client-api.html), unless you are suggesting an alternative to CXF?

[wing328]

Yes, that's the list of HTTP libraries supported. CXF client is not supported yet and we would welcome contribution from the community to support that.

You mentioned Jersey (1.x) has conflicts when being used in conjunction with CXF and that's why I suggested other HTTP libraries, which might work with CXF. Do you also encounter conflicts when using other HTTP libraries with CXF?

[wing328]

And here is the contributing guideline: https://github.com/swagger-api/swagger-codegen/blob/master/CONTRIBUTING.md

[wing328]

@peteryhwong do you need help from us to add CXF client support to the Java client?

[peteryhwong]

@wing328 thanks for asking.

Actually I was thinking if it would not be better if the generation for jersey2, default and cxf would be abstracted to the level of JAX-RS. So that the only difference between them would be the binding at build time. This is so that they would share the same code base.

The problem is that CXF does not provide a thread safe implementation of JAX-RS client. See https://issues.apache.org/jira/browse/CXF-6774

Let me know what you think.

[wing328]

@peteryhwong Is it correct to say that you can use the Java API client with Jersey2 library to talk to your Java CXF-specific Rest server without issue and you're trying to make the API client (jersey2) conforms to Java CXF following some sort of best practice?

cc @fehguy to see if he's any feedback on this particular topic.

[fehguy]

@peteryhwong there are many ways to solve this--in most cases, people are very happy to choose a compatible client runtime and have a stand-alone client SDK. They don't care about the abstraction necessarily, and the selection of the base library is all that matters. I don't personally think that complicating the generator with levels of abstraction helps the end users much at all.

[peteryhwong]

@fehguy @wing328 Thanks for this.

I agree end users might not care as long as if they do not mind the quality or the correctness of the generated code or ever needing to debug through them...

I am thinking in terms of maintaining different implementation of JAX-RS client templates when we could use the same JAX-RS client template for all these implementations. My thinking is around helping to increase the quality of the template, the generated code and also to reduce the complexity of maintaining them.

The same reason applies to JAX-RS server code generation...

[jfiala]

@wing328 I currently deal with CXF2/3 and would like to improve the CXF server part (to assemble a full usable server) and CXF client part, best both with bean-validation support and same model (#2549). You can assign me #2017 + #2549 if you like, I plan to do this in the next week(s)...