-
Notifications
You must be signed in to change notification settings - Fork 6k
[Jaxrs-cxf-cdi] Add beanvalidation annotations updated #4615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…gger-codegen into jaxrs_cxf_cdi_beanval
| @ApiResponse(code = {{{code}}}, message = "{{{message}}}", response = {{{returnType}}}.class{{#returnContainer}}, responseContainer = "{{{returnContainer}}}"{{/returnContainer}}){{#hasMore}},{{/hasMore}}{{/responses}} }) | ||
| public Response {{nickname}}({{#allParams}}{{>queryParams}}{{>pathParams}}{{>headerParams}}{{>bodyParams}}{{>formParams}}{{#hasMore}}, {{/hasMore}}{{/allParams}}) { | ||
| return delegate.{{nickname}}({{#allParams}}{{#isFile}}inputStream, fileDetail{{/isFile}}{{^isFile}}{{paramName}}{{/isFile}}, {{/allParams}}securityContext); | ||
| return delegate.{{nickname}}({{#allParams}}{{#isFile}}fileInputStream, fileDetail{{/isFile}}{{^isFile}}{{paramName}}{{/isFile}}, {{/allParams}}securityContext); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, though don't we mean {{paramName}}InputStream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without this change there currently is a compile error in PetApi.java, as the parameter is declared with name fileInputStream instead of inputStream
@Multipart(value = "file", required = false) InputStream fileInputStreamSo, the fix is to modify the returned parameter from inputStream to fileInputStream.
Of course also the parameter name in the method signature could be changed, pls let me know if you prefer it the other way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, because
{{#isFile}} @Multipart(value = "{{paramName}}"{{^required}}, required = false{{/required}}) InputStream {{paramName}}InputStream, @Multipart(value = "{{paramName}}" {{^required}}, required = false{{/required}}) Attachment {{paramName}}Detail{{/isFile}}
The parameter name is generated by {{paramName}}InputStream. fileInputStream is the result of that. So shouldn't we generate here, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thx I'll fix that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx for the hint, now {{paramName}}InputStream is used
| @@ -0,0 +1,53 @@ | |||
| {{#required}} | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This, beanValidationPathParams.mustache, and beanValidationQueryParams.mustache are very similar. I understand the arguments for avoiding reuse across language generators, but I simply don't agree that needs to be the case within a language generator. I think these three files need refactoring to remove the duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, the only difference is that PathParams are always required, so they don't need a check for NotNull, I commented this in beanValidationPathParams.mustache. So we could extract all other annotation checks into a beanValidationCommonParams.mustache.
Regarding cross-language templates using lambdas this is a nice feature of Mustache, but we need green light from @fehguy /@wing328 for cross-language template reuse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, within the language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'll change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx for the hint, the templates are now reused in beanValidationParams.mustache.
| @@ -1,16 +1,33 @@ | |||
| import javax.xml.bind.annotation.XmlEnum; | |||
| import javax.xml.bind.annotation.XmlType; | |||
| @XmlType(name="{{datatypeWithEnum}}") | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we have enum changes in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nickcmaynard With the old version enumClass.mustache there are compile errors, as the generated sample files were out of date. Pls simply try with the old version and then you see the compilation errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that this is a simple case of one PR, two issues. We should get into the habit of one PR, one issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm absolutely with you (if the samples are up to date and compiling).
|
Bunch of code review comments above. Also, still seeing jaxrs-spec sample regeneration... |
|
@nickcmaynard Responded to all review comments, pls let me know if I should adjust the templates in my branch or if you prefer to do a PR on my repo etc. |
|
@nickcmaynard fixed all review comments, pls review :). |
|
The consolidation of beanValidationParams.mustache should be backported to all other languages, created #4636 as reminder. |
| @ApiResponse(code = {{{code}}}, message = "{{{message}}}", response = {{{returnType}}}.class{{#returnContainer}}, responseContainer = "{{{returnContainer}}}"{{/returnContainer}}){{#hasMore}},{{/hasMore}}{{/responses}} }) | ||
| public Response {{nickname}}({{#allParams}}{{>queryParams}}{{>pathParams}}{{>headerParams}}{{>bodyParams}}{{>formParams}}{{#hasMore}}, {{/hasMore}}{{/allParams}}) { | ||
| return delegate.{{nickname}}({{#allParams}}{{#isFile}}inputStream, fileDetail{{/isFile}}{{^isFile}}{{paramName}}{{/isFile}}, {{/allParams}}securityContext); | ||
| return delegate.{{nickname}}({{#allParams}}{{#isFile}}{{paramName}}InputStream, fileDetail{{/isFile}}{{^isFile}}{{paramName}}{{/isFile}}, {{/allParams}}securityContext); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry - just spotted that by the same logic, we probably also want {{paramName}}Detail!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed - added {{paramName}}Detail
| @@ -0,0 +1,53 @@ | |||
| {{#required}} | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can beanValidation.mustache also bring in {{>beanValidationParams}}? There looks like there's more common ground here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the difference here is that in beanValidation.mustache every annotation gets a new line whereas in the params template all annotation share the same line. So I fear we have to keep them separate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - because this template is used for method annotations, you're adding newlines. However, to my knowledge, there's no Java syntax requirement for newlines on method/property annotations - indeed, much like parameter annotations, newlines are about style, rather than syntax.
So - syntactically I think this would be OK without the newlines. What do you think?
I've also noticed you've got some clever integer/decimal handling in here that's missing in beanValidationParams.mustache- should that be ported?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if its better to drop the newlines in favor of having one beanValidationCore.mustache.
Currently they are all duplicated with newlines (beanValidation.mustache) and all in one line (beanValidationParams.mustache).
Let's have a second opinion before I change something here - @wing328 can you give us a thought?
From a beauty of generated code perspective I'd favor the current solution at the cost of having to maintain both. We could add a mustache comment to remind the maintainers. In fact the bigger effort is having to maintain beanValidation*.mustache across all Java languages, but that's a different story...
| <artifactId>swagger-annotations</artifactId> | ||
| <version>[1.5.3,2)</version> | ||
| </dependency> | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section incorrectly indented
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you probably mean the beanvalidation dependency, this is fixed now.
|
@jfiala added a couple more review comments - apologies. Additionally, I'm still seeing sample updates for the jaxrs-spec generator, which is unexpected. |
|
@nickcmaynard updated according to your comments and reset the jaxrs-spec samples to master. |
|
I refined the handling of DecimalMin/DecimalMax to correctly use Min/Max for Integer+Long and DecimalMin/Max for all others (it would be great to have a flag for non-decimal types in CodegenProperty) and added it to both beanValidation.mustache + beanValidationParams.mustache. @wing328 Pls advise if we should merge the two beanValidation template files at the cost of losing the newlines for the ApiModels (the beanvalidation annotations would then always be a one-liner for params and models, but maybe that's even better for readability...). |
I would suggest we go with merging the 2 template files for better readability and see if the community has any feedback. |
|
@jfiala thanks for the PR, which has been merged into master. @nickcmaynard thanks for reviewing the change. |
|
Beanvalidation annotations fully implemented for jaxrs-cxf-cdi |
) * add check for hideGenerationTimestamp swagger-api#4091 * update generated sample with no generated timestamps swagger-api#4091 * add beanvalidation to jaxrs-cxf-cdi swagger-api#4091 * add beanvalidation to jaxrs-cxf-cdi swagger-api#4091 * update crlf * replace tabs * add check for hideGenerationTimestamp swagger-api#4091 * update generated sample with no generated timestamps swagger-api#4091 * add beanvalidation to jaxrs-cxf-cdi swagger-api#4091 * add beanvalidation to jaxrs-cxf-cdi swagger-api#4091 * update crlf * replace tabs * re-generate samples after rebasing swagger-api#4091 * fix handling of inner enum templates swagger-api#4091 * fix InputStream/Multipart imports and fileInputStream variable swagger-api#4091 * fix paramName for files swagger-api#4091 * consolidate beanValidationParams swagger-api#4091 * add paramNameDetail swagger-api#4615 * fix indentation and regenerate samples swagger-api#4615 * reset samples jaxrs-spec to master * update generated samples * adapt Min/Max/DecimalMin/DecimalMax handling for int/long/else * add ModelApiResponse
PR checklist
./bin/to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.shand./bin/security/{LANG}-petstore.shif updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates)2.3.0branch for breaking (non-backward compatible) changes.Description of the PR
add beanvalidation annotation support to jaxrs-cxf-cdi
for details see #4091
This is a re-creation of the PR #4507 to have a clean comparison view.