openapi-generator
openapi-generator copied to clipboard
[java] Combining "properties" and "additionalProperties" in one class generates broken Jackson mapping.
Description
If using both "properties" and "additionalProperties", the generated class extends HashMap and contains plain properties. Like this:
public class Example extends HashMap<...> {
@JsonProperty("a")
private String a;
...
}
Such a class cannot be meaningfully deserialised using Jackson. Jackson puts all the fields as key/value pairs into the HashMap ignoring the plain fields. In provided example getA() would return "null", while get("a") contains the value.
openapi-generator version
Used version: openapi-generator-maven-plugin : 3.3.3
OpenAPI declaration file
Example:
type: object
properties:
a:
type: string
additionalProperties: true
Suggest a fix/enhancement
I would suggest to generate such a class (which has both "properties" and "additionalProperites") as:
public class Example {
private String a;
private HashMap<> otherProperties;
...
}
Similar suggestion in "swagger-codegen" project: https://github.com/swagger-api/swagger-codegen/issues/5187
Any updates on this?
We are facing the very same issue using openapi-generator-gradle-plugin : 4.0.1 and the jaxrs-jersey
generator.
Are there any workarounds beside not using both (i.e. properties
and additionalProperties
) at the same time? Are there any plans to fix it?
Thanks!
Also having problems with serialize/deserialize properly because of this.
Desired approach would be to populate a mustache flag like {{hasAdditionalProperties}} on class level (not vars level), similar to {{isMapContainer}} which is currently true if additionalProperties: true
Then we could use it however we want in mustache to add the otherProperties field and necessary json annotations and builders etc..
The automatic extends HashMap<...>
should not be there, instead users can add that themselves in mustasche by checking the {{hasAdditionalProperties}} flag.
Any updates on this issue?
I think that having a member of HashMap instead of extending HashMap would address the issue. @JsonAnyGetter and @JsonAnySetter are designed for this exactly. Like @FatCash suggested, there could be a feature flag that would allow backward compatibility (though it seems broken right now anyway)
curious if this was ever fixed?
Also having problems with this issue, Any workaround or update ?
Also having problems with this issue, Any workaround or update ?
Hey, Unfortunately not! But you can make customization for it. I have made wrapper over gradle plugin and added some logic. I can share it with you if you are interested in it
@wakedeer I would be interested to see this.
This is related to issues 6146 and 5515
Hello, I faced the same problem. I took a look at the code and it happens that if you use the java generator with configOptions.library set to jersey2 (gradle plugin), it works as you expect.
Unfortunately for me I use the spring generator, I don't know why the behavior hasn't been set for all java generators.
I will maybe propose a fix about that.
I tried to adapt the fix for spring to the jaxrs-cxf generator. It seems to work fine for our usecase but I am not sure how to prevent this from breaking existing code which may rely on the current behavior. So I am still hesitant to open a pull request.
These changes look really good @benfonty . Is there anything left to get this change accepted?
@benfonty can you try merging master to your branch and push again? That should solve the build issue.
@benfonty can you try merging master to your branch and push again? That should solve the build issue.
@jameswynn CI is indeed OK now.
Hello @jameswynn / @benfonty ,
Have you a update for this fix please ?
Thank you so much :)
Is there anything blocking this from making it into the 6.0 release? @wing328 I can update the PR again.
Hi, this issue is blocking my team as well. @Zomzog , @banlevente , @borsch , @javisst , @cachescrubber , @welshm , @MelleD, @atextor, @manedev79, What is the status on this issue? I tried to contact @jameswynn with no success. I'm happy trying to merge this pull request if need be.
Hello, is there an issue with the MR for it not to be merged?