Skip to content

Conversation

@jfiala
Copy link
Contributor

@jfiala jfiala commented Jan 21, 2017

PR checklist

  • Read the contribution guildelines.
  • Ran the shell/batch script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates)
  • Filed the PR against the correct branch: master for non-breaking changes and 2.3.0 branch 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.

@wing328
Copy link
Contributor

wing328 commented Jan 22, 2017

cc @nickcmaynard

@wing328 wing328 added this to the v2.2.2 milestone Jan 22, 2017
@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);
Copy link
Contributor

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?

Copy link
Contributor Author

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 fileInputStream

So, 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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@jfiala jfiala Jan 23, 2017

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}}
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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}}")
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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).

@nickcmaynard
Copy link
Contributor

Bunch of code review comments above. Also, still seeing jaxrs-spec sample regeneration...

@jfiala
Copy link
Contributor Author

jfiala commented Jan 22, 2017

@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.

@jfiala
Copy link
Contributor Author

jfiala commented Jan 23, 2017

@nickcmaynard fixed all review comments, pls review :).

@jfiala
Copy link
Contributor Author

jfiala commented Jan 23, 2017

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);
Copy link
Contributor

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!

Copy link
Contributor Author

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}}
Copy link
Contributor

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...

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@jfiala jfiala Jan 26, 2017

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section incorrectly indented

Copy link
Contributor Author

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.

@nickcmaynard
Copy link
Contributor

@jfiala added a couple more review comments - apologies. Additionally, I'm still seeing sample updates for the jaxrs-spec generator, which is unexpected.

@jfiala
Copy link
Contributor Author

jfiala commented Jan 25, 2017

@nickcmaynard updated according to your comments and reset the jaxrs-spec samples to master.

@jfiala
Copy link
Contributor Author

jfiala commented Feb 4, 2017

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...).

@jfiala
Copy link
Contributor Author

jfiala commented Feb 5, 2017

@wing328 can you pls take a look here and merge this into master, then I we can conclude the beanvalidation (PR #4635).

@wing328
Copy link
Contributor

wing328 commented Feb 5, 2017

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.

@wing328 wing328 merged commit 38c8796 into swagger-api:master Feb 5, 2017
@wing328
Copy link
Contributor

wing328 commented Feb 5, 2017

@jfiala thanks for the PR, which has been merged into master.

@nickcmaynard thanks for reviewing the change.

@jfiala jfiala deleted the jaxrs_cxf_cdi_beanval branch February 5, 2017 16:59
@jfiala
Copy link
Contributor Author

jfiala commented Mar 12, 2017

Beanvalidation annotations fully implemented for jaxrs-cxf-cdi

davidgri pushed a commit to davidgri/swagger-codegen that referenced this pull request May 11, 2017
)

* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants