Default Java client does not support Content-Type "application/xml"

[cacti77]

I have a swagger.yaml with a post method that produces application/json and which consumes XML. Here's an excerpt:

    post:
      summary: Store a model.
      description: Stores the XML content of the specified model.
      consumes:
        - application/xml;charset=UTF-8
      parameters:
        - name: model
          in: body
          description: The model XML you want to store
          schema:
            type: string
          required: true

I generated the Java client from the swagger.yaml using swagger-codegen-cli-2.2.1.jar and the --lang java option. I did not specify a --library option. (I doubt it's relevant but, just in case, I also specified these options in an associated json config file: apiPackage, groupId, artifactId and artifactVersion.)

However when I issue a POST request with an XML string as input I get this error in the client:

com.mycompany.myapi.ApiException: Content type "application/xml;charset=UTF-8" is not supported
        at com.mycompany.myapi.ApiClient.serialize(ApiClient.java:889)
        at com.mycompany.myapi.ApiClient.buildCall(ApiClient.java:1105)
        at com.mycompany.myapi.client.DefaultApi.modelsPostCall(DefaultApi.java:523)
        at com.mycompany.myapi.client.DefaultApi.modelsPostWithHttpInfo(DefaultApi.java:544)

The generated method in com.mycompany.myapi.ApiClient looks like this:

    /**
     * Serialize the given Java object into request body according to the object's
     * class and the request Content-Type.
     *
     * @param obj The Java object
     * @param contentType The request Content-Type
     * @return The serialized request body
     * @throws ApiException If fail to serialize the given object
     */
    public RequestBody serialize(Object obj, String contentType) throws ApiException {
        if (obj instanceof byte[]) {
            // Binary (byte array) body parameter support.
            return RequestBody.create(MediaType.parse(contentType), (byte[]) obj);
        } else if (obj instanceof File) {
            // File body parameter support.
            return RequestBody.create(MediaType.parse(contentType), (File) obj);
        } else if (isJsonMime(contentType)) {
            String content;
            if (obj != null) {
                content = json.serialize(obj);
            } else {
                content = null;
            }
            return RequestBody.create(MediaType.parse(contentType), content);
        } else {
            throw new ApiException("Content type \"" + contentType + "\" is not supported");
        }
    }

In my case obj is a String. It looks like you don't support application\xml. Is this true? If so, how soon can we expect a fix please? Alternatively can you recommend a workaround I can use? I don't mind hacking the generated code to make it work until a proper fix is released.

Related issues

Is this related? http://stackoverflow.com/questions/33937787/how-to-write-swagger-api-that-accepts-xml-in-request-body . @wing328 suggested @splintor create a new issue but I can't tell whether that ever happened.

[cacti77]

I guess one workaround could be to use a Java library other than the default one. But does anyone know which of the other libraries will work with application/xml content type in POST requests?

[wing328]

I think you can add one more check before else:

        } else if (isJsonMime(contentType)) {
            String content;
            if (obj != null) {
                content = json.serialize(obj);
            } else {
                content = null;
            }
            return RequestBody.create(MediaType.parse(contentType), content);
        } else {
            throw new ApiException("Content type \"" + contentType + "\" is not supported");
        }

If the content type contains application/xml, then use one of the methods describe in http://stackoverflow.com/questions/736343/what-is-the-best-way-to-convert-a-java-object-to-xml-with-open-source-apis to convert the Java model into XML string.

Do you think that will work for your use case?

[cacti77]

Thanks @wing328 . Yes I agree we need at least one extra else-if clause and maybe also an isXmlMime() method. In my case however the XML is just a String. It does not correspond to a Java object, or at least not one I have any access to or any interest in parsing. So maybe this would work for me...

        } else if (obj instanceof String) {
            return RequestBody.create(MediaType.parse(contentType), (String) obj);
        } else {
            throw new ApiException("Content type \"" + contentType + "\" is not supported");
        }

I'll give it a try...

[cacti77]

Yup, that worked:).

[wing328]

@cacti77 glad to hear that it works for you. Do you mind submitting a PR to contribute back the enhancement?

[cacti77]

@wing328 I confess I've never done a PR before and I'm on a tight schedule to deliver lots more code. So I'd prefer not if you don't mind. I'm not even sure which file you'd alter to be honest, maybe swagger-codegen/modules/swagger-codegen/src/main/resources/Java/ApiClient.mustache ?? Sorry about that.

[wing328]

@cacti77 that's ok. If I make the change, would you have time to perform testings to confirm?

[cacti77]

@wing328 Yes that should be ok, especially if you give me the pre-built jar to test. I did try building swagger-codegen from master the other day but ran into issues (UnknownHostException for github.com if I recall correctly).

BTW Unfortunately it looks like the default Java client can't handle returning strings for application/xml either. Instead of generating methods in DefaultApi that return ApiResponse<String> I'm getting return type ApiResponse<Void>. So I can't get at the XML payload I should be getting from the server. Let me do further testing to confirm this please. If I do confirm it I'll raise a separate issue. Then maybe we could test the fix to both issues with the one jar if you can wait that long please...

[cacti77]

@wing328 The related client issue for returning XML is #3888 . I think there's a related issue in the Spring server-generated code too; I'll report that later...