No documented way to handle Mono/Flux without Webflux
See original GitHub issueDescribe the bug
- If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible:
- A clear and concise description of what the bug is: the title of an issue is not enough
To Reproduce I have Spring MVC (no spring-webflux) application based on Spring Boot 2.2.6 and Springdoc 1.3.0.
My controllers return Flux and Mono.
By default springdoc’s swagger-ui page displays Flux response as:
{
"prefetch": 0
}
When I include org.springdoc:springdoc-openapi-webflux-core:1.3.0
my application fails to start:
***************************
APPLICATION FAILED TO START
***************************
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springdoc.core.SpringDocWebMvcConfiguration.openApiResource(SpringDocWebMvcConfiguration.java:60)
The following method did not exist:
'void org.springdoc.api.OpenApiResource.<init>(java.lang.String, org.springdoc.core.OpenAPIBuilder, org.springdoc.core.AbstractRequestBuilder, org.springdoc.core.GenericResponseBuilder, org.springdoc.core.OperationBuilder, org.springframework.web.servlet.mvc.method.RequestMappingInfoHandlerMapping, java.util.Optional, java.util.Optional, org.springdoc.core.SpringDocConfigProperties, java.util.Optional)'
The method's class, org.springdoc.api.OpenApiResource, is available from the following locations:
jar:file:/home/pkubowicz/.gradle/caches/modules-2/files-2.1/org.springdoc/springdoc-openapi-webflux-core/1.3.0/9254ae87d259128c266dcb64a8fdefefa776fbcb/springdoc-openapi-webflux-core-1.3.0.jar!/org/springdoc/api/OpenApiResource.class
jar:file:/home/pkubowicz/.gradle/caches/modules-2/files-2.1/org.springdoc/springdoc-openapi-webmvc-core/1.3.0/13bab9bda41e79dbc041c5fb4e564548e7cd0ffd/springdoc-openapi-webmvc-core-1.3.0.jar!/org/springdoc/api/OpenApiResource.class
The work-around is to execute:
SpringDocUtils.getConfig().addResponseWrapperToIgnore(Mono::class.java)
SpringDocUtils.getConfig().addResponseWrapperToIgnore(Flux::class.java)
Expected behavior This use case should be documented - should springdoc-openapi-webflux-core be used or not used, and if not the documentation should explain how to ‘unwrap’ Flux and Mono.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:7 (3 by maintainers)
Top Results From Across the Web
How to handle errors in Spring reactor Mono or Flux?
I think the first error is in the title: "Mono or Flux" is not related with the error handling. Mono can only emit...
Read more >Guide to Spring 5 WebFlux - Baeldung
Handling Errors in Spring WebFlux. Have a look at different methods to gracefully handle errors in Spring Webflux.
Read more >Reactor 3 Reference Guide
This section provides a brief overview of Reactor reference documentation. You do not need to read ... How to handle errors in the...
Read more >Spring WebFlux Tutorial with CRUD Example - HowToDoInJava
In Spring MVC, it is assumed that applications can block the current thread while in webflux, threads are non-blocking by default.
Read more >Web on Reactive Stack - Spring
Why was Spring WebFlux created? Part of the answer is the need for a non-blocking web stack to handle concurrency with a small...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Is this still unsupported? I agree with others that this is a totally valid use case and must be supported
I’ve run into the same problem. springdoc-openai-webmvc-core should be able to handle Mono and Flux return types too.
The suggested workaround above is not sufficient for Flux, because just stripping it is not correct, it should be handled as an array. As a further workaround I had to annotate all endpoints returning a Flux with: