ExternalRefProcessor has numerous problems causing NullPointerExceptions

[samskiter]

Line 63 of ExternalRefProcessor.java attempts to use a property map from a model which may be null:

//If this is a new model, then check it for other sub references
//Loop the properties and recursively call this method;
Map<String, Property> subProps = model.getProperties();
for(Map.Entry<String,Property> prop: subProps.entrySet()){
    if(prop.getValue() instanceof RefProperty){
        RefProperty subRef = (RefProperty)prop.getValue();
        subRef.set$ref(processRefToExternalDefinition(subRef.get$ref(),subRef.getRefFormat()));
    }               
}
swagger.addDefinition(newRef, model);

This is easy to generate with a referenced model that looks like any of the following:

{
    "type": "array",
    "items": {
        "type": "string"
    }
}

or:

{
    "$ref": "./schemas/site.schema.json"
}

I presume there's also some work to be done to make these definitions parse properly

See also: swagger-api/swagger-codegen#1530

[fehguy]

Thanks. The 2nd example, as a model in the #/definitions section is not valid, FYI. The first issue will be addressed.

[samskiter]

Wow. just seen your commits and trying to merge them now... PR incoming to try to address fully

[samskiter]

Sorry, I don't understand how the second example isn't valid. Could you explain a little more please?

Also your current fix would process potentially invalid properties from an array. And would miss this case:

{
    "type": "array",
    "items": {
        "ref": "./schemas/site.schema.json"
    }
}

[fehguy]

having this:

{
   "definitions" : {
      "myModel": {
        "$ref": "./schemas/site.schema.json"
      }
   }
}

is not legal, unless I'm taking your example out of context.

[samskiter]

That seems really counterintuitive

This is legal:

"responses": {
      "200": {
        "description": "Health information from the server",
        "schema": {
          "$ref": "./models/health.json"
        }
      },
    }

and so is this:

"200": {
    "description": "History information for the given user",
    "schema": {
        "$ref": "#/definitions/Activities"
    }
},
[...]
"definitions": {
    "Activities": {
        "type": "object",
        "properties": {
            "offset": {
                "type": "integer",
                "format": "int32",
                "description": "Position in pagination."
            },
            "limit": {
                "type": "integer",
                "format": "int32",
                "description": "Number of items to retrieve (100 max)."
            },
            "count": {
                "type": "integer",
                "format": "int32",
                "description": "Total number of items available."
            },
            "history": {
                "type": "array",
                "items": {
                    "$ref": "#/definitions/Activity"
                }
            }
        }
    },
}

So what you're saying should be legal

[webron]

So I think what @fehguy meant is that normally that use case would not make sense as you're simply referencing something external by naming it internally and referencing that, which seems redundant. That said, after talking with @samskiter on IRC, it seems they do have a use case for that and so it should be supported.

JSON-Schema wise, that structure is valid.

[fehguy]

Thanks @webron I stand corrected :)

The parser doesn't handle this, but if it's a valid schema, it should. I'll look into getting it supported.

[diegode]

#278 is a duplicate of this one, right?

[fehguy]

This should be fixed now.