Java BeanValidation + JAXRS CXF server generator

[jfiala]

Overview

• added interfaces to model language feature support (io.swagger.codegen.languages.features)
• add beanvalidation annotation support
• add new language for CXF client (jaxrs-cxf, server moved to jaxrs-cxf-server)

Language Java

• add beanvalidation annotation support to language java Client-generation: Allow data validation on the client side (using minLength/maxLength) #2549

Language jaxrs-cxf-server (renamed from jaxrs-cxf)

• add beanvalidation annotation support to language jaxrs-cxf Jaxrs-CXF missing mustache variables for javax.validation framework #2615 (using centralized beanValidation.mustache file)
• add spring server generator to jaxrs-cxf (see also Generating Java Rest Client based on CXF  #2017 )
• spring server: support CXF features using CLI-switches:
  • SwaggerFeature
  • WadlGenerator
  • Multipart
  • Gzip
  • Logging
  • automatic BeanValidation (JEE 7+ - BeanValidation 1.1)
• support CXF features for Unittests using CLI switches:
  • Gzip
  • Logging
  • automatic BeanValidation (BeanValidation 1.1)
• support Spring Boot embedded server
• support Spring Boot integration tests

Language jaxrs-cxf (new)

• implement new language and reuse cxf templates (see Generating Java Rest Client based on CXF  #2017)
• generate complete client including pom.xml
• support CXF features for Unittests using CLI switches (see above)

for more details also see former PR #3281

ideas for further issues

CXF minor improvements

• improve CXF QueryParam BeanValidation formatting (currently reused from beanValidation.mustache, but will add a newline after each beanvalidation annotation).
• add separate flags for controlling junit test gzip/logging/... support (is currently generated automatically for server + junit-tests if switched on)* add option to generate Jboss files (jboss-web.xml etc.)
• add a JbossFeature and flag to only generate jboss-specific files if requested
• add flag for switching JAXB annotations on/off
• check for void in apiServiceImpl to suppress the return statement (instead of returnType, which is void for no returnType...)

extracted to issue #4088

Other languages

• check for void in test-templates to generate the correct statement (currently: void response = ....)

  extracted to issue [Java*] Flag for void methods in mustache files #4089

• add BeanValidation annotation support to all Java languages

  extracted to issue [Java*] BeanValidation for all Java languages #4091

• add JbossFeature to other languages generating jboss-web.xml

  extracted to issue [JaxRsCXFServer] Minor improvements BeanValidation/Unittests/Jboss/JAXB #4088

• check JAXRS/CXF languages for consolidation of mustache templates

• it would be great to have automatic contract tests for the different CLI options, pls let me know if I should supply ones (I'd prefer to have automatic unit tests for this, so the mvn build will fail if anything is changing).

  extracted to issue Contract based unit tests #4087

Further CXF improvements

• maybe add further CXF configuration scenarios (blueprint)

[wing328]

@jfiala yup, will continue the review this weekend and merge if no further question from me.

[jfiala]

@wing328 I just did some integration tests using swagger-codegen-maven-plugin, version 2.2.1.
If I run using the maven-plugin, it is unable to find the subtemplate referenced at JavaJaxRS/cxf/queryParams.mustache:
{{>../../java/beanValidation}}
java.lang.RuntimeException: can't load template JavaJaxRS\cxf....\java\beanValidation.mustache

However, at JavaJaxRS/cxf/pojo.mustache the same reference works without troubles.
And both references are working if I use the CLI instead of the maven plugin.
Also setting the templateDirectory at the configuration of the maven plugin doesn't change the behaviour.

Subtemplating across directories in mustache-files hasn't been used in the project so far, so this hasn't popped up yet.

Pls let me know if I should use a copy of beanValidation.mustache for cxf for now until this is analyzed/fixed ...? Should I create a separate issue for this?

[wing328]

Pls let me know if I should use a copy of beanValidation.mustache for cxf for now until this is analyzed/fixed ...? Should I create a separate issue for this?

Please avoid using relative path and use a copy of the mustache file instead.

[jfiala]

@wing328 changed to local copy + successfully verified with maven.

[wing328]

@jfiala I generated the jaxrs-cxf-client using your branch and got the following error when running mvn test:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project swagger-jaxrs-client: Compilation failure: Compilation failure:
[ERROR] /private/var/tmp/jaxrs-cxf-client/tmp5/src/test/java/io/swagger/api/StoreApiTest.java:[110,24] no suitable constructor found for Long()
[ERROR] constructor java.lang.Long.Long(java.lang.String) is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] constructor java.lang.Long.Long(long) is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] /private/var/tmp/jaxrs-cxf-client/tmp5/src/test/java/io/swagger/api/PetApiTest.java:[97,22] no suitable constructor found for Long()
[ERROR] constructor java.lang.Long.Long(java.lang.String) is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] constructor java.lang.Long.Long(long) is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] /private/var/tmp/jaxrs-cxf-client/tmp5/src/test/java/io/swagger/api/PetApiTest.java:[114,31] java.util.List is abstract; cannot be instantiated
[ERROR] /private/var/tmp/jaxrs-cxf-client/tmp5/src/test/java/io/swagger/api/PetApiTest.java:[130,29] java.util.List is abstract; cannot be instantiated
[ERROR] /private/var/tmp/jaxrs-cxf-client/tmp5/src/test/java/io/swagger/api/PetApiTest.java:[146,22] no suitable constructor found for Long()
[ERROR] constructor java.lang.Long.Long(java.lang.String) is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] constructor java.lang.Long.Long(long) is not applicable
[ERROR] (actual and formal argument lists differ in length)

Here is the command I used:

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate \
-i modules/swagger-codegen/src/test/resources/2_0/petstore.yaml -l jaxrs-cxf-client \
-o /var/tmp/jaxrs-cxf-client/tmp5/ 

Did you get similar error when using the jaxrs-cxf-client client?

[jfiala]

@wing328 I did a clean install across the whole swagger-codegen project and it ran successfully without errors, probably because the generated projects themselvers are not verified with mvn clean install automatically...

I verified the errors you had now directly using:
io.swagger.codegen.Codegen -i C:\projects\swagger-codegen_jfiala\modules\swagger-codegen\src\test\resources\2_0\petstore.yaml -l jaxrs-cxf-client -o c:\temp\swagger-codegen-x_cxf_client -c c:\temp\swagger_config.json

swagger_config.json has all CLI flags turned on:

{
"useBeanValidation": "true",
"useGzipFeature": "true",
"useLoggingFeature": "true"
"generateApiTests": "true"
}

And then run mvn clean install on the generated project:
At the test client, currently placeholders are generated for all the parameters with new and the method invocation is not commented out. This is causing the errors during the compilation.
(it was intented to add more comfort for the developer - so they don't have to type the invocations themselves).

I can replace them with "null" and comment out the invocation itself so the generated test cases can be compiled (like this is the case for the Java test cases)?
Alternatively, I can comment out the parameter preparation as well?

Additionally, the jaxrs-cxf (server) now reuses the mustache template of jaxrs-cxf-client (by using the same template path). I think this makes sense, because they are identical, but if you prefer to have strictly separation of languages, I'd have to copy all templates into the mustache template directory JavaJaxRS/cxf/server (and JavaJaxRS/cxf would be the path of the client, or then even better JavaJaxRS/cxf/client to make things clear)?

[wing328]

I can replace them with "null" and comment out the invocation itself so the generated test cases can be compiled (like this is the case for the Java test cases)?

Yes, please.

[wing328]

FYI. For jaxrs-cxf, I got the following errors related to implementation class:

[INFO] -------------------------------------------------------------
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/PetApiServiceImpl.java:[25,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/PetApiServiceImpl.java:[31,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/PetApiServiceImpl.java:[55,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/PetApiServiceImpl.java:[61,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[24,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[30,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[36,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[42,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[60,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/UserApiServiceImpl.java:[66,16] cannot return a value from method whose result type is void
[ERROR] /private/var/tmp/jaxrs-cxf/tmp5/src/main/java/io/swagger/api/impl/StoreApiServiceImpl.java:[24,16] cannot return a value from method whose result type is void
[INFO] 11 errors 

I believe these errors already present in the latest master so I'll create another issue to track it.

[jfiala]

@wing328: fixed the tests, now you can generate with the petstore without results after mvn install.

Regarding Impl.: The "return null;" will be generated only if the returnType is set, I didn't get any errors here! The problem is that "void" is set as returnType, so we need a flag to indicate that the returnType is void, then we can check for this in the mustache templates.

The other server stub generators get around this by using a generic JAXRS-Response, but IMHO it is much better to deal with the "real" objects instead of the generic JAXRS-Response, the Response is then wrapped automatically by CXF.

[jfiala]

@wing328 the current master jaxrs-server doesn't include the apiServiceImpl.mustache, this was not supported there (https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen/src/main/resources/JavaJaxRS/cxf)

To assemble the implementation class correctly (without compile-errors) I need a flag to check if the returnType is void or not to generate correctly.

This should also be fixed in all Java api_test.mustache files, as they all would generate:

// void response = ...

because they all check for returnType and not for void:

// {{#returnType}}{{{returnType}}} response = 

which only compiles because its commented out :).

[wing328]

To assemble the implementation class correctly (without compile-errors) I need a flag to check if the returnType is void or not to generate correctly.

I'll look into that after this PR is merged into master and add the flag if needed.

[jfiala]

great, thank you!

[wing328]

   /**
   * Get integer
   * minimum: 10.0
   * maximum: 100.0
   * @return integer
  **/
  //@Min(10.0)
  //@Max(100.0)
  @ApiModelProperty(example = "null", value = "")
  public Integer getInteger() {
    return integer;
  }

I noticed that @Min and @Max are commented out, probably due to decimal value used instead of integer.

If we can fix the min and max value with respect to the type, we should be able to generate uncommented constraints, right?

[jfiala]

@wing328 Yes exactly, this has been discussed here #2615, if Codegen will output integer values here, we can remove the comments in the template (or use a different mustache variable).

[wing328]

@jfiala I've created the branch jfiala-jaxrs_cxf_2017b with resolved conflicts and will squash and merge the commits (owned by you) into master after all CI tests pass.

[wing328]

@jfiala merged via #4068