1. Atlassian Avatar Atlassian
  2. Tooling and Automation
  3. swagger-request-validator
  4. Issues

Support for Spring Boot 3 (jakarta Namespace)?

Issue #399 resolved
Peter Storch created an issue

Is it planned to support Spring Boot 3 with jakarta Namespace?

Comments (22)

  1. Viktar Patotski

    That would be nice to support. The only thing which holding us from migrating to Spring Boot 3 and native build.

  2. Sven Döring

    I’ll do it.

    But that'll be a major breaking change. No going back after this.

    But Spring Boot 2 will be around for a couple of years.

    Perhaps I introduce a legacy library for the legacy support.

  3. James Navin

    https://bitbucket.org/atlassian/swagger-request-validator/pull-requests/365 This PR was raised to bump to Spring Boot 3, but it does it as a v3 major version bump which I don’t want to do yet.

    Some ideas on how to move forward:

    • New modules for the new breaking versions (in the same way there is a swagger-request-validator-mockmvc-legacy module) (preferred)
    • We elect to decouple the spring submodules from the parent project and allow them to be released on their own cadence (prefer not to do this at this point as it will increase maintenance complexity, but happy to discuss as an option for SRV v3)
    • We wait to release this as a SRV v3 change (no firm plans on when that might happen though)

    ‌

  4. Sven Döring

    The first solution is my favorite, too.
    But I would not prefer the “legacy” name.
    First Spring 2.7 will be officially supported for almost two years. It’s simply not legacy.
    Second it would be chance to correct the naming error I did five years ago. The Spring Boot dependency is not called “springmvc”, it’s called “spring-webmvc”. Hence, the SVR module should be called “swagger-request-validator-spring-webmvc”.

    The new module would be “swagger-request-validator-spring-webmvc” - that’s Jakarta compatible.
    The current one stays “swagger-request-validator-springmvc” until it’s removed in some years - that’s Javax compatible.

  5. Sven Döring

    However the name of the new module will be, it’s not simply a copy with Jakarta imports.
    All current deprecation, e.g. in ``OpenApiValidationInterceptor.java`` should be handled as well.

  6. James Navin

    The new module would be “swagger-request-validator-spring-webmvc” - that’s Jakarta compatible.
    The current one stays “swagger-request-validator-springmvc” until it’s removed in some years - that’s Javax compatible.

    Works for me 👍

  7. Sven Döring

    @lukas_krecan_pb already did a remarkable job doing all the stuff I imagined in https://bitbucket.org/atlassian/swagger-request-validator/pull-requests/351

    One thing I noticed is, that the SVR project has to be build with JDK 17 or higher as this is minimal version for the used Spring Boot dependency.
    The target source can still be JDK 1.8.

    Perhaps the CI has to be updated as well.

    I’ve build his PR locally with 17 and still can use the old springmvc submodule with 8.

  10. Roman Tuchin

    ‌

    This is blocking us from upgrading to Spring Boot 3.

    ‌

    we had the same issue. As workaround I just copied OpenApiValidationClientHttpRequestInterceptor into our code base and compiled it with spring 6/ spring boot 3

  11. Sven Döring

    Is it possible to outsource the Spring MVC submodule to GitHub? So it’s not maintained within the SRV anymore? After all the submodule only has a dependency to the core. It’s not using it in any other way.

    And there are two more PRs for the Spring MVC submodule waiting for quite some time now.

  12. James Navin

    Is it possible to outsource the Spring MVC submodule to GitHub? So it’s not maintained within the SRV anymore? After all the submodule only has a dependency to the core. It’s not using it in any other way.

    If someone wants to fork the module and maintain it outside the SRV I would have no problems with that. The whole point of building it with a core + adapters is that people can build adapters for whatever they want wherever they want.

    And there are two more PRs for the Spring MVC submodule waiting for quite some time now.

    Thats true, and I apologise for that. FWIW I tend to ignore PRs that have merge conflicts or open tasks, so a couple of those PRs fell off my todo list. I can see they’ve both been addressed so will prioritize them for this week.

  14. Roman Tuchin

    with 2.33.1 I’m still having:

    Caused by java.lang.NoSuchMethodError: 'org.springframework.http.HttpStatus org.springframework.http.client.ClientHttpResponse.getStatusCode()' at
    com.atlassian.oai.validator.springweb.client.OpenApiValidationClientHttpRequestInterceptor.fromClientHttpResponse(OpenApiValidationClientHttpRequestInterceptor.java:91)
    com.atlassian.oai.validator.springweb.client.OpenApiValidationClientHttpRequestInterceptor.intercept(OpenApiValidationClientHttpRequestInterceptor.java:65)
    org.springframework.http.client.InterceptingClientHttpRequest$InterceptingRequestExecution.execute(InterceptingClientHttpRequest.java:87)
    org.springframework.http.client.InterceptingClientHttpRequest.executeInternal(InterceptingClientHttpRequest.java:71)

    ‌

  17. Sven Döring

    The latest pull request only covered the Web MVC support for Spring Boot 3.
    The WebClient has been forgotten. 🤔

  18. Roman Tuchin

    would be great if you upgrade this submodule too. We don’t use swagger-request-validator-spring-webmvc because we are on reactive stack (Netty, Flux, Mono) and since there is no support for WebClient/ WebTestClient we decided just to use TestRestTemplate with a interceptor from swagger-request-validator-spring-web-client for doing openapi checks.

  19. Sven Döring

    Do I understand it correctly that you would use the Swagger Request Validater in Webflux if there would be such module?

  23. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Votes
16
Watchers
21