Different fixes in the asyncapi v3 spec examples #543
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/
The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR
The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR
To pass the SQS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed.
To pass the SNS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed.
ctasada
commented
Jan 16, 2024
| @@ -20,4 +20,10 @@ | |||
| public @interface SnsAsyncOperationBinding { | |||
There was a problem hiding this comment.
Both protocol and endpoint are mandatory fields for which I don't think we should provide a default value. This decision automatically generates a breaking change. Without a value, the compilation of any code using this annotation will fail.
The cloudstream-plugin was not generating the operations section of the AsyncAPI spec. Now is fixed and validated. Multiple FIXMEs were fixed and removed too
timonback
approved these changes
Jan 18, 2024
...vshamir/springwolf/asyncapi/scanners/channels/annotation/AsyncAnnotationChannelsScanner.java
Outdated
Show resolved
Hide resolved
...syncapi/scanners/channels/cloudstream/CloudStreamFunctionChannelsScannerIntegrationTest.java
Outdated
Show resolved
Hide resolved
Whe configuring annotations on the class level, the generated Operations didn't have the proper message references. This fixes the latest blocking FIXME
The Schema Properties should support any kind of value, like booleans. Making the property accept `Object` seems a more flexible approach.
timonback
approved these changes
Jan 18, 2024
timonback
pushed a commit
that referenced
this pull request
Jan 19, 2024
* fix: Minor fix to core spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ * fix: Minor fix to sns-plugin spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR * fix: Minor fix to sqs-plugin spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR * Fixed styles * fix: Fixed broken tests * fix: Added support to sqs-plugin to generate the minimum needed values To pass the SQS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed. * fix: Added support to sns-plugin to generate the minimum needed values To pass the SNS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed. * fix: Removed small batch of pending FIXMEs * fix: Removed small batch of pending FIXMEs * fix: Removed small batch of pending FIXMEs * fix: Fixed the cloudstream-plugin The cloudstream-plugin was not generating the operations section of the AsyncAPI spec. Now is fixed and validated. Multiple FIXMEs were fixed and removed too * fix: Removed unused methods * fix: Fixed CloudStream operation action typo * fix: Removed unneeded channelId field from ChannelObject * fix: Fixed some code analysis complains * fix: Fixed Operation messages bug Whe configuring annotations on the class level, the generated Operations didn't have the proper message references. This fixes the latest blocking FIXME * fix: Schema Properties The Schema Properties should support any kind of value, like booleans. Making the property accept `Object` seems a more flexible approach.
timonback
added a commit
that referenced
this pull request
Jan 26, 2024
* feat(ui): prepare springwolf for AsyncApi 3.0 (wip) feat(ui): remove testing code feat(ui): remove asyncApi 2.0 hint about publish/subscribe feat(ui): add parsing error boundary feat(ui): add license chip feat(ui): add notification.service.ts feat(ui): rename Channel to ChannelOperation also fix bindings feat(ui): update asyncapi mapper (wip) feat(ui): add todos feat(ui): update asyncapi models to v3 chore(ui): split model packages chore(ui): download asyncapi document only once refactor(ui): re-organize components chore(ui): use asyncapi v3 mock chore(ui): remove IE support chore(ui): move favicon.ico to assets * feat(asyncapi): update package description * feat(asyncapi): add todos * Enhancement: Add More Spec Details to the UI (#517) * test: ignore line ending in generated specs assertions Is failing in Windows OS Refs #378 * refactor(kafka): add primitive payload, example of `minimum` value To visualize in UI Refs #378 test(kafka): add primitive types More data to demonstrate + type badges check * refactor(ui): add schema properties template To reuse for primitive types Refs #378 * feat(ui): add `type` badge to schema payload header No intuitive way to check whether the payload is an objects or a string Refs #378 * feat(ui): add minimum and maximum values to the spec`s model Feature request Refs #378 * feat(ui): display primitive type info Feature request. Only properties has info displayed Refs #378 * feat(ui): display minimum and maximum values Feature request. Refs #378 * Revert "test: ignore line ending in generated specs assertions" This reverts commit 07a6b30. * feat: Replaced usage of jAsyncAPI by the new springwolf-asyncapi module (#523) * feat: Replaced usage of jAsyncAPI by the new springwolf-asyncapi module We migrate from jAsyncAPI, with support for AsyncAPI v2, to the new SpringWolf-AsyncAPI module, which supports AsyncAPI v3. This PR is only a first step. Plenty of tests are still not working and others are partially commented. Please take a look to the multiple FIXMEs in the code * Replaced Springwolf-Core Message related classes by their Springwolf-AsyncAPI equivalent. (#527) Fixes some FIXMEs and removes duplicated classes * AsyncAPI v3 Migration Fixes (#533) * fix: Multiple fixes related with Channel Messages Some of the tests are failing due to some AssertJ recursion issue. Help is welcome * fix: Minor properties fixes * fix: Fixes to AMQP Some fixes to the AMQP plugin and example (Still not finished) * fix: Minor properties fixes * fix: Migrated asyncapi.json examples to v3 * fix: Migration to AsyncAPI v3 As per https://www.asyncapi.com/docs/migration/migrating-to-v3 For a channel with multiple messages, you specify multiple key-value pairs. For a channel with just one message, you use a single key-value pair. That means that the use of 'oneOf' is removed. * fix: Improved support for Channel Messages Fixed different bugs and limitations with the publishing of Messages in a Channel with the AsyncAPI v3 spec * fix: Fixed Channel Merger When merging Channels, the messages were not merged. This is now fixed. * fix: Added basic support for Operations Still plenty of errors, but Operations are now appearing in the AsyncAPI v3 output. * fix: AsyncAPI module test * Feat/asyncapi v3 UI fixes (#539) * fix: Added missing comparison code Those missing annotations were causing some tests to fail * fix: AMQP operation binding As per documentation, 'deliveryMode' can only be 1 or 2. The default value 0 was incorrect * fix: Added Channel Ref to Operation * test: update asyncapi.json files based on current state in the branch Generate asyncapi.actual.json files by running in _springwolf_examples_ folder: `../gradlew test --tests "**.ApiIntegrationTest" --continue` * test(kafka): update asyncapi model * feat(ui): move asyncapi v3 changes --------- Co-authored-by: Carlos Tasada <ctasada@gmail.com> * fix: Fixed core tests (#540) * fix: Fixed core tests Fixed the failing tests after migrating to AsyncAPI v3 * fix: Fixed AMQP integration The AMQP was adding both 'exchange' & 'queue' keys, but it should only include the one related with the binding type. Also, deliveryMode can be ONLY 1 or 2, the default value 0 which was used in different places is wrong. * fix: Fixed AMQP integration The AMQP was adding both 'exchange' & 'queue' keys, but it should only include the one related with the binding type. Also, deliveryMode can be ONLY 1 or 2, the default value 0 which was used in different places is wrong. * Feat/message as component (#541) * feat: move messages to components * feat: add ChannelMessageReference allows to link from an operation to the message within a specific channel * chore: update asyncapi.json * feat(ui): update after message was moved to components * fix(ui): map operation binding correctly * feat(core): remove ChannelMessageReference * test(example): simplify creation of asyncapi.json files * test(asyncapi): change channel messages type back to Message * refactor(asyncapi): rename MessageReference static message Better indicate what the reference points to * chore: spotless * test: fix DefaultChannelsServiceIntegrationTest * test(kafka): remove duplicated primitite-topic consumer * feat(core): use AsyncApi 3.0 OperationAction * feat(ui): show contact info * chore: update dependency list * Different fixes in the asyncapi v3 spec examples (#543) * fix: Minor fix to core spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ * fix: Minor fix to sns-plugin spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR * fix: Minor fix to sqs-plugin spec example The asyncapi test sample had a minor issue when validated with https://studio.asyncapi.com/ We need to properly configure those values, something that I will take care of in the next PR * Fixed styles * fix: Fixed broken tests * fix: Added support to sqs-plugin to generate the minimum needed values To pass the SQS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed. * fix: Added support to sns-plugin to generate the minimum needed values To pass the SNS Binding AsyncAPI validation, we need to provide some required fields. This commit adds the minimum values needed. * fix: Removed small batch of pending FIXMEs * fix: Removed small batch of pending FIXMEs * fix: Removed small batch of pending FIXMEs * fix: Fixed the cloudstream-plugin The cloudstream-plugin was not generating the operations section of the AsyncAPI spec. Now is fixed and validated. Multiple FIXMEs were fixed and removed too * fix: Removed unused methods * fix: Fixed CloudStream operation action typo * fix: Removed unneeded channelId field from ChannelObject * fix: Fixed some code analysis complains * fix: Fixed Operation messages bug Whe configuring annotations on the class level, the generated Operations didn't have the proper message references. This fixes the latest blocking FIXME * fix: Schema Properties The Schema Properties should support any kind of value, like booleans. Making the property accept `Object` seems a more flexible approach. * Feat/asyncapi 3: more fixes (#550) * chore: typo * fix: correct Listener=receive, Publisher=send operationAction * feat(kafka): handle kafka message binding key * chore: update example json * feat(core): all operation include the action in the id refactor: rename operationName to operationId * feat(cloud-stream): align asyncapi.json structure * feat(ui): show message when bindings are missing * chore: resolve open FIXME * chore: fix dependencies * Support exclusiveMinimum and exclusiveMaximum (#560) * feat(ui): add exclusiveMinimum and exclusiveMaximum values to the spec`s model Feature request Refs #378 * refactor(ui): reimplement range temple model For further extension Refs #378 * feat(ui): add support for exclusiveMinimum and exclusiveMaximum Feature request Refs #378 * refactor(ui): separate schema range as a component For further extensions and maintenance Refs #378 * test: add exclusiveMinimum to example Dto To test changes visually Refs #378 * chore: Split ChannelScanner and OperationScanner (#562) --------- Co-authored-by: Nikita Marunko <aerfus@yandex.ru> Co-authored-by: Carlos Tasada <ctasada@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of the used examples to test the code were not passing the AsyncAPI v3 validation process. Here we fix them and leave the code ready for a next iteration of improvements