Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional in interface not supported #106

Closed
magx2 opened this issue Dec 15, 2023 · 10 comments
Closed

Optional in interface not supported #106

magx2 opened this issue Dec 15, 2023 · 10 comments
Labels
bug Something isn't working

Comments

@magx2
Copy link

magx2 commented Dec 15, 2023

I just found that if you have Optional in interface it does not get unpacked:

public interface Foo {
    Optional<String> getOptionalFoo();
}

Produces this YML:

components:
  schemas:
    Foo:
      type: object
      properties:
        optionalFoo: # here
          type: object
          properties:
            value:
              type: string

instead of unpacked Optional:

components:
  schemas:
    Foo:
      type: object
      properties:
        optionalFoo: # here
          type: string

If you want to reproduce it you can look at my repo: https://github.com/magx2/openapi-maven-plugin-error

@kbuntrock
Copy link
Owner

I don't really know how to handle this case since we often consider "Optional" as a java syntaxic sugar - not translated into json.

For example, with Spring MVC with a default configuration, if you return an optional in a controller : it return the original object or null.

Do you have the use case only for you Dtos? Or for your api body/return contracts declarations also? *

Example for the second case :
Optional getSomeData(@RequestParam Optional id)

@magx2
Copy link
Author

magx2 commented Jan 3, 2024

I think that there is a misunderstanding.

If I have an optional in class it's being unpacked to concrete type. On the other side optional in interfaces are not unpacked.

I would like to see the same behavior in interfaces as we have with classes

@kbuntrock
Copy link
Owner

Oh, got it! Indeed, I got it wrong. This is a fine request, added to the todo. :)

@kbuntrock kbuntrock added the bug Something isn't working label Jan 25, 2024
@magx2
Copy link
Author

magx2 commented Feb 6, 2024

Same problem would appear in parameters:

public String optionalParameter(@RequestParam("optional") Optional<String> optional) {
    return optional.orElse("default");
}
parameters:
  - name: optional
    in: query
    required: true # HERE!
    schema:
      type: object
      properties:
        value:
          type: string

@kbuntrock
Copy link
Owner

kbuntrock commented Feb 6, 2024

I think that there is a misunderstanding.

If I have an optional in class it's being unpacked to concrete type. On the other side optional in interfaces are not unpacked.

I would like to see the same behavior in interfaces as we have with classes

Are you sure it is linked to class vs interface? I could not reproduce this bug. For me the only unwrapping actually in the app is if an Optional is used as a webservice response. Everywhere else, there is no unwrapping. (before the PR I'm working on)

@magx2
Copy link
Author

magx2 commented Feb 6, 2024

Here you have code to reproduce it magx2/openapi-maven-plugin-error@198880c

It's not a problem of not unpacking Optional in interface but rather not setting required to false. I thought it's similar code space so I've pointed it here. If you want you can create new issue

@kbuntrock
Copy link
Owner

Ok, got it. No, it's ok, no worries, I'll keep working on my current MR.

@kbuntrock
Copy link
Owner

Hello Martin.
Do you mind testing if you have the time the current version on the "dev" branch? And check if it fix this bug well for you?

Thank you very much by advance. ;)

@magx2
Copy link
Author

magx2 commented Feb 26, 2024 via email

@kbuntrock
Copy link
Owner

Nice, thank you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants