"integer" isn't seen as a valid type by ModelRef

version 2.6.1

I’m trying to create a ModelRef to use in a Header so I can have headers in my responses.

private ModelRef integerModel = new ModelRef("integer");
private Header xRateLimitLimit = new Header("X-RateLimit-Limit", "The defined maximum number of requests available to the consumer for this API.", integerModel);

private ArrayList<ResponseMessage> responseList = newArrayList(
        new ResponseMessageBuilder()
            .code(400)
            .headersWithDescription(defaultHeaders)
            .message("Bad Request").responseModel(responseCodeModel).build());

I am making a separate ModelRef and Header because I plan on using them quite a few times, and it’s easier than creating a new one over and over.

When I do this, I expect "type":"integer","format":"int32" in my swagger doc, instead I am getting "$ref":"#/definitions/integer".

I have used "number", "long", and "string", and everything works as expected. Instead of using $ref, it uses type, as expected. This doesn’t happen with "integer". This should work according to the OpenAPI-Specification. The common name "integer" should have a type of integer and a format of int32.

---

example:

    private ModelRef integerModel1 = new ModelRef("integer");
    private ModelRef integerModel2 = new ModelRef("long");
    private ModelRef integerModel3 = new ModelRef("string");

A different model for each header.

    private Header xRateLimitLimit = new Header("X-RateLimit-Limit", "The defined maximum number of requests available to the consumer for this API.", integerModel1);
    private Header xRateLimitRemaining = new Header("X-RateLimit-Remaining", "The number of calls remaining before the limit is enforced and requests are bounced.", integerModel2);
    private Header xRateLimitReset = new Header("X-RateLimit-Reset", "The time, in seconds, until the limit expires and another request will be allowed in. This header will only be present if the limit is being enforced.", integerModel3);

I then put those headers into a map…

    private Map<String, Header> defaultHeaders = new HashMap<String, Header>(){{
        put("xRateLimitLimit", xRateLimitLimit);
        put("xRateLimitRemaining", xRateLimitRemaining);
        put("xRateLimitReset", xRateLimitReset);
    }};

…so that I can use it in ResponseMessageBuilder…

private ArrayList<ResponseMessage> responseList = newArrayList(
        new ResponseMessageBuilder()
            .code(400)
            .headersWithDescription(defaultHeaders)
            .message("Bad Request").responseModel(responseCodeModel).build());

And this is applied to my main Docket with…

            .globalResponseMessage(RequestMethod.GET, responseList)

Output:

"headers":{
    "xRateLimitReset": {
        "type": "string",
        "description": "The time, in seconds, until the limit expires and another request will be allowed in. This header will only be present if the limit is being enforced."
    },
    "xRateLimitLimit": {
        "description": "The defined maximum number of requests available to the consumer for this API.",
        "$ref": "#/definitions/integer"
    },
    "xRateLimitRemaining": {
        "type": "integer",
        "format": "int64",
        "description": "The number of calls remaining before the limit is enforced and requests are bounced."
    }
}

It’s attempting to find a model called integer, instead of the using the integer type.

I have a feeling this is related to SpringFox since I’m using ModelRef. If this belongs somewhere else, please let me know. Thanks!

[dilipkrish]

@ahatzz11 Closing the PR wasn’t intending to be rude or any reflection of the contribution. Any and every contribution is very much appreciated. There is a ton of requests in the backlog and would love contributions. I was just tidying up before releasing 2.7.0 and the PR was closed because it was not a valid change. So thank you for you contribution and apologies if that wasn’t clearly explained. Let me try to explain…

The reason is that it was initially modeled as int is because internally this is how we represent the following types

• 32 byte integers as int (Integer.TYPE or Integer.class)
• 64 byte integers as long (Long.TYPE or Long.class)

Historically we have never maintained the type representation as a function of how it needs to appear in a swagger description. They are really internal representations. That is to say that the internal data structures need to have the fidelity to represent integers as (integer, format=int32) and long as (integer, format=int64), so going with just integer is lossy. FWIW, the representation we chose to go with at the time this library was created was to go with the names of the value types (int and long).

Another way to look at this is that we could project our internal models to RAML or Api Blueprint, and still be agnostic of the service description format and be able to distinguish these internal representations.

Hope that makes sense.

[ahatzz11]

@dilipkrish Didn’t think it was rude, just wanted to make sure I understood the reasoning behind it all. Definitely makes sense, thanks for the explanation! Everything is working now (and as designed 😉)! I’ll close this issue out. Thanks for the help.

Also - I’m excited for some of the stuff in 2.7.0. Keep up the good work!