Jersey2 trying to use CXF classes

[mursilsayed]

We are trying to use the java client library in our SpringBoot application to connect with Rustici Cloud. When we call any service using the client library, we are getting this error

 ERROR org.apache.cxf.jaxrs.utils.JAXRSUtils - No message body reader has been found for class com.rusticisoftware.cloud.v2.client.model.CourseListSchema, ContentType: application/json
  - should not throw exception when asked to fetch list of courses *** FAILED *** (1 second, 109 milliseconds)
    javax.ws.rs.client.ResponseProcessingException: No message body reader has been found for class com.rusticisoftware.cloud.v2.client.model.CourseListSchema, ContentType: application/json
    at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:437)
    at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:390)
    at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:320)
    at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:308)
    at com.rusticisoftware.cloud.v2.client.ApiClient.deserialize(ApiClient.java:564)
    at com.rusticisoftware.cloud.v2.client.ApiClient.invokeAPI(ApiClient.java:696)
    at com.rusticisoftware.cloud.v2.client.api.CourseApi.getCourses(CourseApi.java:943)
    at com.worldmanager.platform.modules.eLearning.library.RusticiIntegrationService.getCourses(RusticiIntegrationService.scala:24)
    at com.worldmanager.test.units.modules.eLearning.RusticiServiceSpec.$anonfun$new$3(RusticiServiceSpec.scala:23)
    at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)

In our application we are consuming some other services through CXF client. I can see that scormcloud-api-v2-client-java is using jersey2 as its java api client(instead of the default (okhttp-gson). Since our application is consuming some other services through CXF client, it seems like the scormcloud-api-v2-client-java library is picking up CXF Response implementation instead of the json implementation to read from the api.

To verify the issue, I created a separate test SpringBoot application just for testing scorm cloud via java client library. I worked fine as the application doesnt have any other functionality that uses cxf.

I also built custom-rustici-client-library from Swagger Codegen using your api specification. I didn't use jersey2 as the java api client. i.e. I went without specifying the library ( thus using the default option okhttp-gson) . I used the following using the config file for generating the client library.

{
    "apiPackage" : "api",
    "invokerPackage" : "com.rusticisoftware.cloud.v2.client",
    "apiPackage" : "com.rusticisoftware.cloud.v2.client.api",
    "modelPackage" : "com.rusticisoftware.cloud.v2.client.model",
    "groupId": "com.rusticisoftware.cloud.v2.client",
    "artifactId": "scormcloud-api-v2-client",
    "artifactId": "1.0.3"
} 

I was able to consume the rustici cloud api using this custom-rustici-client-library.

I have two questions.

1. Is there a reason to use jersey2 as the java api client library?
2. Can this client library be re-published using default client library(okhttp-gson) instead of jersey2 so that we dont have to maintain the client library ourselves?

[mursilsayed]

swagger-api/swagger-codegen#5574 discusses about a similar issue

[rainmore]

The best solution is to allow the user to change their preferred HTTP client.

[DillGromble]

Hi there,

Apologies for the trouble you've had with the Java client. It does look like you're running into issues of conflicting Jax-RS implementations. To address your questions: the main reason we generated this library with jersey2 as the client language is that is that much our codegen configuration is shared with server stubs for various services. This in large part is to make things easier to maintain.

I can understand your reservations about maintaining a library yourself. However, we can't change this client as we have people using it actively. Adding an additional supported library might be an option if we see more people having issues like this. We currently don't have the resources or demand to do so.

That is in large part why we chose to adhere to the OpenAPI specification. We wanted anyone to be able to quickly bootstrap a client using swagger-codegen (or other tool) in whatever language or framework worked best in their project.

That being said, there is an existing codegen language for JaxRs-CXF which seems like it'd be your best option.

Hope this helps to answer some of your questions. I will keep an eye on the issues in swagger-codegen with jersey2 and CXF to see if there is a way we can mitigate this issue in the future.