POC for Polymorphism #890

dabeck81 · 2024-08-01T12:53:46Z

POC for Polymorphism

netlify · 2024-08-01T12:54:03Z

✅ Deploy Preview for springwolf-ui ready!

Name	Link
🔨 Latest commit	`af6c89e`
🔍 Latest deploy log	https://app.netlify.com/sites/springwolf-ui/deploys/66e451f834e37f0008b0c23e
😎 Deploy Preview	https://deploy-preview-890--springwolf-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

springwolf-examples/springwolf-kafka-example/src/test/resources/asyncapi.yaml

...java/io/github/springwolf/core/asyncapi/scanners/common/payload/internal/PayloadService.java

.../main/java/io/github/springwolf/core/asyncapi/scanners/common/payload/NamedSchemaObject.java

...java/io/github/springwolf/core/asyncapi/components/examples/walkers/DefaultSchemaWalker.java

...in/java/io/github/springwolf/core/asyncapi/schemas/converters/SchemaTitleModelConverter.java

...java/io/github/springwolf/core/asyncapi/scanners/common/payload/internal/PayloadService.java

...ringwolf/core/asyncapi/scanners/channels/annotations/AsyncAnnotationChannelsScannerTest.java

timonback · 2024-08-09T11:54:48Z

...loudstream/asyncapi/scanners/channels/CloudStreamFunctionChannelsScannerIntegrationTest.java

TypeToClassConverter#extractClass is only used by the cloudstream plugin now.
A next step (possibly outside of the PR) can be to apply the same Class -> Type change to the cloudstream plugin and so that TypeToClassConverter can be fully removed, right?

yes, that was what I was thinking as well

springwolf-examples/springwolf-kafka-example/src/test/resources/asyncapi.yaml

springwolf-core/src/test/resources/schemas/xml/annotation-definitions-xml.json

timonback · 2024-08-09T12:01:57Z

springwolf-examples/springwolf-amqp-example/src/test/resources/asyncapi.json

@@ -227,7 +227,7 @@
        },
        "name": "io.github.springwolf.examples.amqp.dtos.AnotherPayloadDto",
        "title": "AnotherPayloadDto",
-        "description": "Another payload model",
+        "description": "",


Were you able to find out, why the description disappears?

The description that is shown is the description of the schema, so the logical place to show this description is on the Schema-component, as it is already.
The description that is on that place, should be the one of the @asyncmessage, in my opinion.

The reason why the description is not anymore shown, is that Swagger creates now the reference to the schema-object, whereas before it was a hardcoded reference by Springwolf itself. Due to removing that hardcoded reference, we do not receive anymore the full schema, but an already referenced schema-object on the payload, without a description.
If this is a blocking matter, what could be done is:

Either, fetching the schema from the swagger-reference and fetching the description via that way.

Either, setting the description on the reference-schema with a custom modelConverter.

Good point regarding the location of the description and it seems that the description does not belong here.

Springwolf has two ways to specify an optional description via the Swagger Schema annotation (belongs to the schema) and via the AsyncOperation annotation (belongs to the operation).

Can the description be null in that case instead of an empty string?
~~(I am currently unsure, whether the ui selects the description already from the correct location)~~

EDIT: Just compared the PR preview https://deploy-preview-890--springwolf-ui.netlify.app/springwolf-ui/asyncapi-ui.html#channel-string-topic and the current state https://demo.springwolf.dev/springwolf-ui/asyncapi-ui.html#channel-string-topic for the string topic and the ui seems to handle channel Operation description and Message description correctly.

timonback · 2024-08-09T12:13:09Z

springwolf-examples/springwolf-kafka-example/src/test/resources/asyncapi.json

@@ -25,8 +25,8 @@
    "another-topic": {
      "address": "another-topic",
      "messages": {
-        "io.github.springwolf.examples.kafka.dtos.AnotherPayloadDto": {
-          "$ref": "#/components/messages/io.github.springwolf.examples.kafka.dtos.AnotherPayloadDto"
+        "java.util.ListIo.github.springwolf.examples.kafka.dtos.AnotherPayloadDto": {


The case of List in combination with batch listeners may be debatable.
I've added a ConsumerRecord listener to the kafka example. Using the extractable-classes, do you see an easy way to auto-extract the actual class?
Another modelConverter?

hmm, I must admit, that indeed the consumerRecord does not get extracted the way it should. A "modelConverter" is always a good idea to adapt the schema to the way we would like. I think this is a same case as with the MonetaryExample, where Swagger does not see the defined fields of the class

I haven't tried the example on the current code of Springwolf, how it generates. I suppose quite the same.

An idea that comes to my mind is that maybe for each of the different "support-bindings", some custom modelconverters could be added on the classpath. So for example this case: The class ConsumerRecord belongs to the Kafka framework, so only when that binding is selected, the support for consumerRecord could be added with a custom modelconverter. You could define that modelconverter bean on the SpringwolfKafkaBindingAutoConfiguration.

I suppose each framework has its special quircks, so adding custom modelconverters for each of them to the binding-autoconfiguration seems like the way to go.

I don't know what you think.

I added some code as mentioned in #891 (comment)

If you don't feel strongly about it, I would like to minimize breaking changes and continue to extract List

timonback · 2024-08-09T12:25:13Z

...wolf-core/src/main/java/io/github/springwolf/core/asyncapi/schemas/SwaggerSchemaService.java

+            Schema payloadSchema = resolvedSchema.schema;
+            preProcessSchemas(payloadSchema, preProcessSchemas, type);
+            HashMap<String, Schema> postProcessSchemas = new HashMap<>(preProcessSchemas);
+            postProcessSchema(preProcessSchemas, postProcessSchemas, actualContentType);


I am probably missing something:
Is this part of the duplication, you mentioned? It seems that the same schemas are post processed again and/or the resolvedSchema is not post-processed.

Side-note: I didnt know about ResolvedSchema. Great improvement to use it.

The duplication is more in the methods, I simply duplicated, like:

postProcessSchema
processAsyncApiPayloadAnnotation
processSchemaAnnotation
processCommonModelConverters

Those 4 methods are twice in the swaggerSchemaService. Once for the old way of defining schemas (still in use for headers) and once for the new way of defining schemas (for defining the payload).
So, as part of a next refactoring the header-generation could be adapted to make also use of "resolvedSchema" and then those duplicate methods can go away.

extracted from springwolf#890 Co-authored-by: David Beck <[email protected]>

extracted from #890 Co-authored-by: David Beck <[email protected]>

extracted from springwolf#890 Co-authored-by: David Beck <[email protected]>

* refactor(core): rename NamedSchemaObject to PayloadSchemaObject extracted from #890 Co-authored-by: David Beck <[email protected]> * refactor(core): use SchemaType constants --------- Co-authored-by: David Beck <[email protected]>

Merge from Timon's repo

also add to schemas section to allow publishing

dabeck81 mentioned this pull request Aug 1, 2024

Support for a polymorphic payload #891

Closed

timonback reviewed Aug 1, 2024

View reviewed changes

timonback reviewed Aug 9, 2024

View reviewed changes

timonback added a commit to timonback/springwolf-core that referenced this pull request Aug 16, 2024

fix(core): handle ref in xml example

d3f7d0e

extracted from springwolf#890 Co-authored-by: David Beck <[email protected]>

timonback mentioned this pull request Aug 16, 2024

fix(core): handle ref in xml example #921

Merged

timonback added a commit to timonback/springwolf-core that referenced this pull request Aug 16, 2024

refactor(core): rename NamedSchemaObject to PayloadSchemaObject

e2f0ed0

extracted from springwolf#890 Co-authored-by: David Beck <[email protected]>

timonback added a commit that referenced this pull request Aug 16, 2024

fix(core): handle ref in xml example (#921)

1746421

extracted from #890 Co-authored-by: David Beck <[email protected]>

timonback added a commit to timonback/springwolf-core that referenced this pull request Aug 16, 2024

feat(core): add SchemaTitleModelConverter

9e896f8

extracted from springwolf#890 Co-authored-by: David Beck <[email protected]>

timonback mentioned this pull request Aug 16, 2024

feat(core): add SchemaTitleModelConverter #923

Closed

David Beck and others added 13 commits September 7, 2024 17:46

fix issue springwolf#874

0d8c4fe

POC: adding polymorphism on payload

618c7a3

POC: adding polymorphism on payload

ce00e38

POC: refactoring for support for inline-schema's

359fd38

POC: refactoring for support for inline-schema's

ddef043

POC: refactoring for support for inline-schema's

e175ce7

feat(ui): update server model

632633d

feat(kafka): add ConsumerRecord to example

e1ccab9

test(core): align test setup

b44c365

test(core): minor changes

db2a5bc

resolving pull-request remarks

0cc629d

chore: fixes after rebase

4345bfe

feat(core): extract types using extractableClasses

628e55b

dabeck81 closed this Sep 9, 2024

dabeck81 force-pushed the master branch from 8dc9262 to 59dfa3b Compare September 9, 2024 07:52

Merge pull request #1 from timonback/dabeck81

a6d9cae

Merge from Timon's repo

timonback reopened this Sep 10, 2024

timonback added 2 commits September 11, 2024 20:10

feat(ui): handle inline schemas

3a0a620

test(ui): update ui tests

55acbc6

timonback and others added 6 commits September 12, 2024 23:00

feat(core): add inline schemas

68eef35

also add to schemas section to allow publishing

feat(ui): update mapping of example

1e1eb65

feat(e2e): refactor publishing and simplify payloadName retrieval

24282f2

feat(core): remove empty description

bb0e006

trim newline on yaml-file in kafka-test

8b8a252

Merge branch 'master' into master

af6c89e

timonback merged commit 096c8c4 into springwolf:master Sep 13, 2024
24 of 25 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

POC for Polymorphism #890

POC for Polymorphism #890

dabeck81 commented Aug 1, 2024

netlify bot commented Aug 1, 2024 •

edited

Loading

timonback Aug 9, 2024

dabeck81 Aug 11, 2024

timonback Aug 9, 2024

dabeck81 Aug 11, 2024 •

edited

Loading

timonback Sep 11, 2024 •

edited

Loading

timonback Aug 9, 2024

dabeck81 Aug 11, 2024

timonback Sep 11, 2024

timonback Aug 9, 2024

dabeck81 Aug 11, 2024

POC for Polymorphism #890

POC for Polymorphism #890

Conversation

dabeck81 commented Aug 1, 2024

netlify bot commented Aug 1, 2024 • edited Loading

✅ Deploy Preview for springwolf-ui ready!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dabeck81 Aug 11, 2024 • edited Loading

Choose a reason for hiding this comment

timonback Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

netlify bot commented Aug 1, 2024 •

edited

Loading

dabeck81 Aug 11, 2024 •

edited

Loading

timonback Sep 11, 2024 •

edited

Loading