Repository navigation
Jersey2 trying to use CXF classes #5
Description
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.
- Is there a reason to use
jersey2as the java api client library? - Can this client library be re-published using default client library(
okhttp-gson) instead ofjersey2so that we dont have to maintain the client library ourselves?
Activity
[-]Jersey2 SDK trying to use CXF classes[/-][+]Jersey2 trying to use CXF classes[/+]mursilsayed commentedon Sep 28, 2020
swagger-api/swagger-codegen#5574 discusses about a similar issue
rainmore commentedon Sep 28, 2020
The best solution is to allow the user to change their preferred HTTP client.
DillGromble commentedon Sep 29, 2020
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
jersey2as 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-codegenwith jersey2 and CXF to see if there is a way we can mitigate this issue in the future.