Swagger core 2.0.0 #56
Conversation
# Conflicts: # src/main/scala/io/swagger/scala/converter/SwaggerScalaModelConverter.scala # src/test/scala/ModelPropertyParserTest.scala
|
I've published this branch as a snapshot to https://oss.sonatype.org/content/repositories/staging/
|
|
An issue I noticed with this one: the optional values in scala case classes are documented as objects with 2 fields: "empty", "defined" |
|
@zsoltherpai could you be hitting #55 ? |
Sorry that was my mistake, the converter has not been correctly registered. Another issue I noticed: Option[AnyRef] works fine now but having problems with Option[AnyVal] For example Option[Int] shows up as Annotating the field as a temporary workaround didn't work (still type: object) |
|
@zsoltherpai I've reproduced the issue where One workaround is to use Option[BigInt] instead of Option[Int]. The type erasure issue only seems to affect primitives like Int, Boolean etc. |
|
@zsoltherpai I fixed the issue with the annotations being ignored in my fork of swagger-scala-module. There is a sample that demonstrates the fix - https://github.com/pjfanning/swagger-akka-http-sample |
|
Thanks, it works better now. Bumped into some new issues.
Option[Array[String]] - in an attempt to make the field non-required -
fails with a nullpointer exception in the jackson model resolver. Then I
tried plain Array[Integer] annotated with @Schema(required = false) . This
doesn't do much. However @Schema(name = "whatever") does make the field
non-required.
…On Sun, Oct 7, 2018 at 11:59 AM PJ Fanning ***@***.***> wrote:
@zsoltherpai <https://github.com/zsoltherpai> I fixed the issue with the
annotations being ignored in my fork of swagger-scala-module
<https://github.com/swagger-akka-http/swagger-scala-module>. There is a
sample that demonstrates the fix -
https://github.com/pjfanning/swagger-akka-http-sample
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB72xfmNyAHmDpNVmuG-9qLZRClkiIGpks5uidCTgaJpZM4V4zcr>
.
|
|
Setting any property of @Schema to a non-default value does the trick (eg
defaultValue).
On Fri, Oct 12, 2018 at 12:09 AM Zsolt Herpai <zsolt.herpai@gmail.com>
wrote:
… Thanks, it works better now. Bumped into some new issues.
Option[Array[String]] - in an attempt to make the field non-required -
fails with a nullpointer exception in the jackson model resolver. Then I
tried plain Array[Integer] annotated with @Schema(required = false) . This
doesn't do much. However @Schema(name = "whatever") does make the field
non-required.
On Sun, Oct 7, 2018 at 11:59 AM PJ Fanning ***@***.***>
wrote:
> @zsoltherpai <https://github.com/zsoltherpai> I fixed the issue with the
> annotations being ignored in my fork of swagger-scala-module
> <https://github.com/swagger-akka-http/swagger-scala-module>. There is a
> sample that demonstrates the fix -
> https://github.com/pjfanning/swagger-akka-http-sample
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#56 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AB72xfmNyAHmDpNVmuG-9qLZRClkiIGpks5uidCTgaJpZM4V4zcr>
> .
>
|
|
Would this PR enable enum support? Is there anything I can do to support the effort? |
|
https://github.com/pjfanning/swagger-akka-http-sample has an example of how to handle an enum with swagger-2 - not ideal but I haven't been able to fix the automatic handling of enums |
|
Wow great work, how can we make the project move forward especially with this PR? |
|
I have a fork that supports swagger 2 / OpenAPI 3 - https://github.com/swagger-akka-http/swagger-scala-module |
|
@pjfanning Do you use the swagger-scala-module only? I started having a look at using it in swagger-play but there's a significant amount of changes, not sure it's worth the effort considering that other alternatives such as Tapir already provides OAS 3.0 support (in a totally different way than swagger-play obviously). |
|
@gaeljw I'm keeping alive swagger-scala-module (in a fork) because it is used in some existing libs that can use the updated code. It is good to see alternatives because swagger-scala-module is based on Java reflection and there are issues with type erasure that can be avoided with alternative approaches. I just gave up on this PR because it is time consuming to keep it updated but with little chance of it being merged. |
Relates to #49