In a definition section, examples for string objects are over-quoted. For example, this stanza from an input yaml
# input yaml
definitions:
Id:
type: string
example: example from def
is rewritten by swagger-codegen as
# resulting yaml from swagger-codegen
Id:
type: "string"
example: "\"example from def\""
Explicitly quoting the input example text has no effect.
The above example is for python-flask and nodejs-server. I suspect other servers generate the same yaml.
This bug does not occur for examples within object definitions. For example, the following stanza works as expected:
Allele:
type: "object"
properties:
id:
$ref: "#/definitions/Id"
location_id:
$ref: "#/definitions/Id"
replacement:
$ref: "#/definitions/Sequence"
example:
id: "Allele example"
location_id: "Allele example"
replacement: "Allele example"
2.2.2
https://github.com/reece/vmc-openapi/blob/master/spec/vmc.yaml
swagger-codegen generate -l python-flask -i ../spec/vmc.yaml -o python-flask
The following issues are vaguely related.
@reece thanks for reporting the issue. When I clicked on https://github.com/reece/vmc-openapi/blob/master/spec/vmc.yaml, I got a 404.
If you've time, I would suggest you to try the latest master as well to see if there's by any chance the issue may have been addressed already.
@wing328: Yes, this affects latest master (42a5a13fe) as well.
I worked up an minimal example at https://gist.github.com/reece/7d343afd3638fc530c3d3607b57ababd.
definitions:
Def1:
type: "string"
example: word
Def2:
type: "string"
example: two words
Def3:
type: "string"
example: "quotedword"
Def4:
type: "string"
example: "two quoted words"
Def5:
type: "object"
properties:
namespace:
type: "string"
example: "NCBI"
accession:
type: "string"
example: "ENST000001234.5"
With the command line swagger-codegen generate -l python-flask -o 5460 -i 5460.yaml (2.2.2 and master), I see this:
$ grep example 5460/swagger_server/swagger/swagger.yaml
example: "\"word\""
example: "\"two words\""
example: "\"quotedword\""
example: "\"two quoted words\""
example: "NCBI"
example: "ENST000001234.5"
@wing328 and @reece : I've noticed this problem too when generating json format in the JavaPlayFramework codegen. I don't know where this "json" is generated so I could not fix it myself.
I use this code in the generator:
@Override
public Map<String, Object> postProcessSupportingFileData(Map<String, Object> objs) {
Swagger swagger = (Swagger)objs.get("swagger");
System.out.println("swagger" + swagger.toString());
if(swagger != null) {
try {
objs.put("swagger-json", Json.pretty().writeValueAsString(swagger));
} catch (JsonProcessingException e) {
LOGGER.error(e.getMessage(), e);
}
}
return super.postProcessSupportingFileData(objs);
}
And use it like this in the .mustache file:
{{{swagger-json}}}
yaml like this
ReturnStatus:
type: string
enum:
- NotReturned
- Recycled
- Trashed
- InTransit
- InvestigationPending
- Lost
description: "Device's return status"
example: InTransit
return json like this
"ReturnStatus" : {
"type" : "string",
"description" : "Device's return status",
"example" : "\"InTransit\"",
"enum" : [ "NotReturned", "Recycled", "Trashed", "InTransit", "InvestigationPending", "Lost" ]
},
Can be reproduced using all the above examples using this simple line:
java -jar swagger-codegen-cli.jar generate -i swagger.yaml -l swagger -o generated
I dug a little bit in the code and I'm pretty sure this is coming from swagger-core. When swagger-codegen process the models, the value is already there "InTransit" instead of just InTransit without the quote.
I've submitted a fix but I don't know if it's the legitimate way to fix it. But it work :) Let's see if it will be accepted and merged to the master!
If this is wrong at swagger-core side (or swagger-parser), I would propose we try to solve it there (or at least open an issue in the responsible project)?
@ePaul : In fact, after spending a couple of time on this, I'm pretty sure the bug is on our side. Check my PR and let me know if it makes sense :)
@reece the fix by @JFCote has been merged into master. Please pull the latest to give it another try.
Thanks for the notice. I've moved on the from that project and no longer
have need for swagger. I won't be able to test in the near term.
On Wed, Jul 26, 2017 at 1:09 AM, wing328 notifications@github.com wrote:
@reece https://github.com/reece the fix by @JFCote
https://github.com/jfcote has been merged into master. Please pull the
latest to give it another try.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/swagger-api/swagger-codegen/issues/5460#issuecomment-317981172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGrjd0_VVolBPSevHr4q3qM9eOaz6hZks5sRvQ3gaJpZM4NFc0H
.
@reece no problem. I hope you will find Swagger Codegen useful in your upcoming projects.
@reece FYI. We released v2.2.3 with 11 new generators 2 weeks ago. You may want to check it out.
@wing328 I can't confirm that v2.2.3 fixes the issue. At least for nodejs-server code.
@sebdi you mean you "can" confirm, right?
@wing328 No, I mean the issue is still present in v2.2.3
@wing328 @sebdi I'm seeing this in the node and php clients with path parameters (using the latest version of the swagger-codegen-cli docker image.
Is it possible that the fix needs to be applied to the CodegenParameter class as well?
Sample operation yaml to reproduce:
paths:
'/user/{username}':
get:
tags:
- user
summary: Get user by user name
description: ''
operationId: getUserByName
produces:
- application/xml
- application/json
parameters:
- name: username
in: path
description: 'The name that needs to be fetched. Use user1 for testing. '
required: true
type: string
x-example: foo123
Happy to open a separate issue as well. Maybe related to https://github.com/swagger-api/swagger-codegen/issues/6484?
@phillbaker yes please open a new issue with details for tracking instead and link it to this one.
Most helpful comment
@reece FYI. We released v2.2.3 with 11 new generators 2 weeks ago. You may want to check it out.