-
-
Notifications
You must be signed in to change notification settings - Fork 35
fix: unable to get model class when using arrays in schema #207
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
fix: unable to get model class when using arrays in schema #207
Conversation
…o use the x-parser-schema-id property of the source schemafirst, then try the property name.
…d-stream-template into crushton/fix-201_null_modelClass
…s that should have been their own class; the schema name is going to be correct more often from using x-schema-parser-id instead when appropriate; broke all args constructor for schemas that are arrays with this commit.
…/CameronRushton/java-spring-cloud-stream-template into crushton/fix-201_null_modelClass
…ow correctly created for array types
…moved need for a tentative class name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So very happy you're supporting this, Cameron, thanks very much!
Kudos, SonarCloud Quality Gate passed!
|
🎉 This PR is included in version 0.11.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
Resolves an NPE when attempting to use a null modelClass and additionally makes the asyncapi files in the issues usable. As part of making them usable, I changed how inner schemas are identified and created which includes schemas of type array.
The problem is that we created the modelClass map using the x-schema-parser-id as keys, then as we go through the schema when generating the template, we use the property name instead of the x-schema-parser-id. This leads to returning a null modelClass.
Now, we use the x-parser-schema-id property of the source schema first, then if that turns up nothing, try the property name to get the modelClass. Additionally, the modelClass map is populated with all possible keys for a modelClass. For example, there may be an entry like 'MyAnonSchema' -> ModelClass and another that has the same modelClass copied but for another key like 'anonymous-schema-3' -> ModelClass. This means that we're nearly guaranteed to get a hit when we're getting a modelClass by name.
This also works for $ref. Example:
Normally, the schema referred by my-prop will be empty since they’re no data for that ModelClass. Now, the otherSchema ModelClass will be picked up instead because we’ve accounted for this mapping indicated by the $ref. The name ‘my-prop’ isn’t lost though, yes we’re using the OtherSchema class for my-prop, but we’ll use @JsonProperty("my-prop") on OtherSchema otherSchema like we have been doing before. It’s debatable whether we still call the variable name my-prop throughout, ie OtherSchema myProp.
Aside from some spacing adjustments, this is the biggest change in the existing snapshots (two snapshots use this schema, one being the first test, the solace binder test).

solace binder test difference in schema (OLD -> NEW)
The all args constructor has been refactored into another partial as well.
Related issue(s)
Resolves #194 and resolves #201 which is a duplicate.