Closed maddingo closed 9 months ago
see #232 for possible workarounds.
Would be nice to have a cleaner solution for this.
But I fear I don't have a solution at hand. I have to think about it.
open questions:
Mono<ResponseEntity<...>>
?ResponseEntity<Mono<...>>
?The safe route is to offer both and don't think to much about the questions. ;-) It would need a configuration, probably a boolean switch.
switching the order of the ResponseEntity
wrapper and the Mono
wrapper or something else would have to change this: https://github.com/openapi-processor/openapi-processor-base/blob/ccfc44a4fb4f3bdb6f2a247412ba3e927e72d42f/openapi-processor-core/src/main/kotlin/io/openapiprocessor/core/converter/ApiConverter.kt#L298-L303
another thought, maybe combining Mono
/ResponseEntity
handling into a single wrapper would make things easier...
I created a test case for this and am now trying to implement it. This requires some changes to -base. I struggle to find a nice flow. ./gradlew build issues errors with missing dependencies. All I need is to publish -core to the local maven repo. Any tips on how to do that? I figured out how to disable the signing, but then gradle complains about missing pom.xml.asc.
./gradlew
should work. It builds on github after commit so there should be no missing dependencies.
I work mostly in the base project and I'm usually running ./gradlew check
from the root of base (i.e. not in the core sub folder, although that should work too). It runs all unit and all integration tests.
If you are in openapi-processor-spring you can uncomment the //includeBuild '../openapi-processor-base'
line in the settings.gradle
(in the root folder of openapi-processor-spring).
Gradle will then automatically use (and build) the base stuff from the included project as part of the spring project.
Sometimes it helps to remove the .gradle
& build
folders to get a clean start....
You probably set up gnupg signing for your project. I added some code in the base repo that allows switching off the signing with a env variable.
For a description of the different combination of reactive types and ResponseEntity see https://docs.spring.io/spring-framework/reference/web/webflux/controller/ann-methods/responseentity.html
Extending result
like this is an interesting approach. Nice about it is, that result
can be configured by path. We can simply override it where needed.
a surprisingly low number of changes.. :-)
released with 2024.1
did change some details in core and moved the integration test from here to core.
Thanks!
Currently, return type>` is supported.
ResponseEntity<Mono<ModelClass>>
or ResponseEntity<FluxExample:
Whereas without the response entity wrapped it looks like this there is no way to set the response status deliberately.
I had a look at the source code, but to me there is no obvious way of doing this. Should it be possible to specify a generic type as result mapping, should it be a flag. If you point me in the right direction, I can make an effort of providing a PR.