springmvc OpenApiValidationInterceptor should be easier to extend/customize

Issue #376 resolved
Marc LEVISSE created an issue

Hi folks !

I'm trying to customize a little bit the OpenApiValidationInterceptor to be able to validate requests/responses among a list of OpenAPI spec files instead of a single one

To do that, I'm forced to copy the OpenApiValidationService which is package protected
Same issue within response validation that checks the caching response which refer to the OpenApiValidationContentCachingResponse which is package protected too

So as I'm not forced to copy the OpenApiValidationFilter too, could you tell me why are those class all package protected, and would it be a solution to allow customizing them ?

I think it should be great to be able to provide custom ValidationReportHandler too 😉

I would be happy to contribute by the way if multiple OpenAPI spec files validation is feature that would be useful for the community

Thx !

Comments (12)

  1. Sven Döring

    So you wish that the OpenApiValidationService will have an public constructor as well as the class of the OpenApiValidationContentCachingResponseWrapper?

    The ValidationReportHandler is already customizable as it is only an interface and its only implementation is the DefaultValidationReportHandler.

    Do you need more public’s while we are at it?

  2. Marc LEVISSE reporter

    I would be glad to show case my current implementation to make it easier to face the whole needs

    But as a summary, I built:

    • a CompositeOpenApiValidationInterceptor that takes multiple OpenApi specs (OpenApiValidationService instances) and which iterate on each of them while validating requests/responses (the trick is still to handle "no operation found" across multiple files as, in consequence, over N files, you should ideally meet N-1 "validation.request.path.missing" messages that should be filtered and only raising the missing error while it was not found on any of the files. I will have to deal with potential duplicates (I won’t meet that case, but more generally it perhaps should be considered as an input constraint ?))
    • => to be able to implement it (as OpenApiValidationService, OpenApiValidationContentCachingResponseWrapper and OpenApiValidationFilter are package protected), I was to duplicate them in my CompositeOpenApiValidationInterceptor package
    • by being forced to duplicate OpenApiValidationService and OpenApiValidationFilter, I was then obliged to retrieve ResponseUtils and ResettableRequestServletWrapper
    • => those 4 classes were not customized and used as is (but copied)

    ‌

    That’s all !

    I was indeed able to implement a custom ValidationReportHandler so as to customize logging vs exception raising vs doing nothing regarding a "mode" I provided as a parameter (mode whose value depends regarding the context:

    • in tests I set mode to “raise exception” for responses for instance, so as we are aware at dev/test phase that our implementation does not match specs)
    • in runtime webapp, I set requests validation mode as “raise exception” but only “logging” for responses (as we talk about an existing implementation already deploy in production, that works, but sometime does not match exactly the specs)

    Feel free to chat if you are interested in that use cases !

    I will certainly face soon other use cases as I will have to handle tricky things such as handling routes that should be validated other that should not, and most of all Multipart ones etc.

    ‌

    Ah one last thing, I faced little tricks for “operation not allowed” errors:

    • I had to filter “validation.requests.*” in response validation, unless I had raising errors in validateResponse (perhaps should it be standard in OpenApiValidationInterceptor ? or a parameter ?)
    • I customized the report handler to raise a MethodNotAllowedException instead of InvalidRequestException that would somehow lead to a 400 BAD REQUEST which is not correct to my specifications (we raise 405 METHOD NOT ALLOWED)

    ‌

    Anyway, thx a lot for the great work already done !

  3. Marc LEVISSE reporter

    Hi @Sven Döring !

    I could not build your issue_2776 branch cause wiremock 2.32.0 is not available on Maven central.

    ‌

    [INFO] ------------------------------------------------------------------------
    [INFO] Reactor Summary for Swagger Request Validator 2.25.2-SNAPSHOT:
    [INFO] 
    [INFO] Swagger Request Validator .......................... SUCCESS [ 17.841 s]
    [INFO] swagger-request-validator-core ..................... FAILURE [ 11.259 s]
    [INFO] swagger-request-validator-pact ..................... SKIPPED
    [INFO] swagger-request-validator-wiremock ................. SKIPPED
    [INFO] swagger-request-validator-restassured .............. SKIPPED
    [INFO] swagger-request-validator-mockmvc .................. SKIPPED
    [INFO] swagger-request-validator-mockmvc-legacy ........... SKIPPED
    [INFO] swagger-request-validator-springmvc ................ SKIPPED
    [INFO] swagger-request-validator-spring-web-client ........ SKIPPED
    [INFO] swagger-request-validator-examples ................. SKIPPED
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  31.202 s
    [INFO] Finished at: 2022-02-21T09:52:27+01:00
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal on project swagger-request-validator-core: Could not resolve dependencies for project com.atlassian.oai:swagger-request-validator-core:jar:2.25.2-SNAPSHOT: Could not find artifact com.github.tomakehurst:wiremock:jar:2.32.0 in repo.default (http://maven-releases.server.citobi.be/repository/maven-central/) -> [Help 1]
    [ERROR] 
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR] 
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
    [ERROR] 
    [ERROR] After correcting the problems, you can resume the build with the command
    [ERROR]   mvn <args> -rf :swagger-request-validator-core
    

    ‌

    here they seems to tell that wiremock should be wiremock-jre8 after 2.27.2 version

    https://wiremock.org/docs/download-and-installation/

    ‌

    https://mvnrepository.com/artifact/com.github.tomakehurst/wiremock

    vs

    https://mvnrepository.com/artifact/com.github.tomakehurst/wiremock-jre8

    KR,

    Marc

  4. Sven Döring

    I had the same issue.

    For the build I replaced the “wiremock” dependency with “wiremock-jre8”. Fortunately it’s just a test dependency.

    I will create an issue about this missing dependency.

  5. Marc LEVISSE reporter

    I’ve been able to build your branch locally, upgrade my dependencyManagement to use the newly built 2.25.2-SNAPSHOT version of swagger-request-validator-springmvc, removed the “copied” classes and used the now public ones in my custom CompositeOpenApiValidationInterceptor, and it works fine !

    Thx a lot !

    Do you have an idea of schedule for PR merge then release in Maven Central ? thx so much !

  6. Sven Döring

    Do you have an idea of schedule for PR merge then release in Maven Central ?

    You’ll never know at this project.

    Might be this night (GMT) or in three months.

    ‌

  7. Log in to comment