openapi-processor / openapi-processor-spring

an OpenAPI 3.0 & 3.1 interface & model java code generator for Spring Boot
https://docs.openapiprocessor.io
Apache License 2.0
40 stars 9 forks source link

Support wrapping result type in Mono #239

Closed maddingo closed 9 months ago

maddingo commented 10 months ago

Currently, return type ResponseEntity<Mono<ModelClass>> or ResponseEntity<Flux>` is supported.

Example:

   @Override
    public Mono<ResponseEntity<Quote>> getQuote(String id, ServerWebExchange exchange) {
        return quotes.getQuote(id)
            .map(ResponseEntity::ok)
            .switchIfEmpty(Mono.just(ResponseEntity.notFound().build()));
    }

Whereas without the response entity wrapped it looks like this there is no way to set the response status deliberately.

    @Override
    public ResponseEntity<Mono<Quote>> getQuote(String id, ServerWebExchange exchange) {
        return ResponseEntity.ok(quotes.getQuote(id));
    }

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.

hauner commented 10 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:

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...

maddingo commented 10 months ago

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.

hauner commented 10 months ago

./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....

maddingo commented 9 months ago

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.

maddingo commented 9 months ago

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

hauner commented 9 months ago

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.. :-)

hauner commented 9 months ago

released with 2024.1

did change some details in core and moved the integration test from here to core.

Thanks!