If you have a ticket you wish done I could look into that this weekend. We are using the generator at work so it is only fair to give something back
If private fields are allowed I would be happy to leave it as it is, if not, well, I guess I would change it then.
What's the latest status on Handlebars support?
Are we good to start building out template sets in handlebars to ship with the OAG?
I saw that this PR was merged a while back:
Map<String, Object> with an undefined structure. We’re also looking to separate template logic from generation logic so we don’t need to have a method in a base type that requires knowledge of the template engine in order to monkey patch it’s compiler.
Hello everyone. We have been switching over to your OpenAPI generator and finally after quite some time things are looking pretty good. It is generating for the most part spring, javascript, python, and dotnet clients reasonably well. I have a couple of questions, hopefully this is the place to ask but if not please direct me to where, about generation with OpenAPI annotations originating from Java CXF + Reactor endpoints...
I have an endpoint like below:
1) How do I represent the multipart request properly?
2) The query params, if they have a @Default, are rendered as 2 different parameters.
Any help would be appreciated.
@POST
@Produces(APPLICATION_JSON)
@Consumes(MULTIPART_FORM_DATA)
@Operation(
operationId = "uploadToS3",
summary = "Upload files",
description = "Upload files to S3",
parameters = {
@Parameter(name = "client", description = "Client name", required = true),
@Parameter(name = "project", description = "Project name", required = true),
@Parameter(name = "unique", description = "Use unique names", in = QUERY)},
requestBody = @RequestBody(
content = @Content(
mediaType = MULTIPART_FORM_DATA,
schema = @Schema(type = "string", format = "binary"),
encoding = @Encoding(
name = "file",
contentType = APPLICATION_OCTET_STREAM))),
responses = {
@ApiResponse(
responseCode = "200",
description = "The uploaded files",
content = @Content(
array = @ArraySchema(
schema = @Schema(implementation = FileResult.class))))})
public Flux<FileResult> uploadFiles(@PathParam("client") String client,
@PathParam("project") String project,
@QueryParam("unique") @DefaultValue("false") boolean unique,
@Context HttpServletRequest request)BTW: In the csharp-dotnetcore template we had to adjust the use of value in the query param iterator because it conflicted with variables named the same. Seems just giving it a more obscure name would prevent the collision against something that could be a common property name.
@jimschubert - it was these blocks specifically in the api.mustache. The inner value conflicted with a parameter type that happened to be named value as well. You can see where I just renamed the inner var value to v to solve my issue for now.
foreach (var kvp in {{packageName}}.Client.ClientUtils.ParameterToMultiMap("{{#collectionFormat}}{{collectionFormat}}{{/collectionFormat}}", "{{baseName}}", {{paramName}}))
{
foreach (var v in kvp.Value)
{
requestOptions.QueryParameters.Add(kvp.Key, v);
}
}Also, for what it is worth here are some other things I ran into which may or may not of been my usage:
- In the
typescript-angularMaven POM configuration it seemed that when I addedmodelsfor the<modelPackage>it munged the package. I had to explicitly set it tomodelfor the value and it worked. Without it, it seemed to produce an oddmodels.modelor something of the sorts I can't remember. - In the Java generated POMs, there were simpler dependency setups that could be used, especially with the Spring ones. Out of the box, none of them compiled for me though. In this case, I had my own parent POM to apply but it really carried over some Spring BOM ones which cleaned up the POM.
- Python seemed to work out-of-the-box though I have not tested it yet. I briefly tested the Java+Jersey one and it worked for the methods I tried.
Just responding to my own questions above:
1) The "duplicate" parameters only occur when I had the in property on the annotations. It doubled up with the JAX-RS annotation and looked to treat them as individual parameters. I know there are some rules mentioned to what takes precedence but removing the in property from the annotation in the @Operation solved the issue for me.
2) I "think" I have the multiple-file/multipart upload working using something like this below. At least code-wise and in Swagger UI it gets acknowledged as a multiple file upload.
@POST
@Path("/uploads")
@Produces(APPLICATION_JSON)
@Consumes(MULTIPART_FORM_DATA)
@Operation(
operationId = "uploadFilesExample",
summary = "Upload files",
description = "Upload files",
parameters = {
@Parameter(name = "client", description = "Client name", required = true),
@Parameter(name = "project", description = "Project name", required = true),
@Parameter(name = "unique", description = "Use unique names")},
requestBody = @RequestBody(
content = @Content(
mediaType = "multipart/form-data",
schema = @Schema(implementation = MultiRequest.class),
encoding = @Encoding(
name = "file",
contentType = "application/pdf, image/png"))),
responses = {
@ApiResponse(
responseCode = "200",
description = "The uploaded files",
content = @Content(
array = @ArraySchema(
schema = @Schema(implementation = FileResult.class)))),
@ApiResponse(responseCode = "400", description = "Bad request"),
@ApiResponse(responseCode = "401", description = "Unauthorized"),
@ApiResponse(responseCode = "403", description = "Forbidden"),
@ApiResponse(responseCode = "409", description = "Version Conflict"),
@ApiResponse(responseCode = "500", description = "Backend Error")})
@PreAuthorize("isSecured(#client, 'projects', 'write')")
public Flux<FileResult> uploadFiles(@PathParam("client") String client,
@PathParam("project") String project,
@QueryParam("unique") @DefaultValue("false") boolean unique,
@Parameter(hidden = true) @Context HttpServletRequest request)
{
return null;
}
class MultiRequest
{
@ArraySchema(
schema = @Schema(type = "string", format = "binary", description = "image file"))
public List<String> file;
}
We’re not planning on allowing non-Mustache templates shipped with oag until we have significant improvments on architecture. Namely, we’ve discussed a testable object instance/interface which is passed to templates rather than a
Map<String, Object>with an undefined structure. We’re also looking to separate template logic from generation logic so we don’t need to have a method in a base type that requires knowledge of the template engine in order to monkey patch it’s compiler.
Thanks for the update. Are these changes being planned for 5.0?
I'm working on a nodejs-express generator. Still work in progress. If you want to see what I've done so far, please let me know.
[main] INFO o.o.codegen.DefaultGenerator - OpenAPI Generator: openapi-yaml (documentation)
[main] INFO o.o.codegen.DefaultGenerator - Generator 'openapi-yaml' is considered stable.
{
"openapi" : "3.0.0",
"info" : {
"title" : "My Microservice API",
"description" : "......",
"termsOfService" : "http://sam.adidas.com/ts",
"license" : {
"name" : "Proprietary",
},
"version" : "1.2.0"
},
"servers" : [ {....
} ],
"paths" : {
"/users" : {
"x-summary" : "Users Collection",
"x-description" : "Retrieve user infomation"
"get" : {
"tags" : [ "users" ],
"summary" : "find",
"description" : ...",
"operationId" : "findUsers",
"parameters" : [ {...} ],
"responses" : {....},
}
We have some mocking laying around here - and it even gets easier with
deriving via .. so in about 5min-1h you can have a full generated json-mock-server up & running.. even with domain-specific data..I think i have to write a blogpost or so about that .. :/
@jimschubert
I think we should copy all the path from a vendor specific extension from path to each operation
Do you think it makes sense in the grand scheme of OpenAPI generator?