ngs-doo / dsl-json

High performance JVM JSON library
https://dsl-platform.com
BSD 3-Clause "New" or "Revised" License
1.01k stars 106 forks source link

Allow to customize scanned annotations #222

Closed hellnn closed 1 year ago

hellnn commented 3 years ago

Is it possible to deserialize missing nested objects to null reference, rather than empty objects?

For example:

{name: ''foo"}

class Event { private String name; private Source source } class Source { private String name }

In this case after deserialization event source field should be null

zapov commented 3 years ago

I would expect it works like that by default?

Technically when its missing it should be the value assigned in the ctor. So if its null in ctor it should remain null. If its empty in ctor it should remain empty

hellnn commented 3 years ago

The problem is, if you use the java validation api, then the @NotNull annotation works only for null fields, so you cannot validate bean required fields and for example Jackson deserializes missing fields as null by default

zapov commented 3 years ago

I'm not sure I understand what you mean by validating them.

If you want to force having this field in JSON, you can do that by turning mandatory on for this field. It can still be null even when mandatory. Mandatory means it must be present in the JSON. That way you can validate it and force it to be expected in JSON.

If your class does not have empty ctor and instead expects all properties during construction, it will use default value for this type (unless you override it) which in this case is null. So if its missing then it will be null.

If your class has empty ctor then it will leave this field alone unless its specified in the JSON. This way you can setup default values for your fields in your ctor.

So the behavior you want is possible and unless you initialized that property in ctor to empty instance I would expect it already behaves like that. Is that not whats going on?

Leaving the field as is, instead of setting it to null when its missing in JSON seems to me like much better default behavior.

zapov commented 3 years ago

You can take a look at this test: https://github.com/ngs-doo/dsl-json/commit/c7f6d145b7c8aaca1232b35959aef7fe4fd3c750

It shows explicit expected behavior of DSL-JSON. If field is non-nullable, but DSL-JSON detects that its still null after deserialization it will assign default value for it. For strings that is empty string, for references this is instance from empty ctor.

hellnn commented 3 years ago

Ok, There is using @JsonAttribute, but in my case this annotation not use, because classes are generated by OpenApi generator, I think the default behavior should be for fields as nullable true if annotation is absent

zapov commented 3 years ago

NonNull annotation should behave the same as nullable=false in JsonAnnotation

Anyway... its hard to me to understand the problem you are having. I suggest making a PR with a test in which you show the behavior and expected result.

hellnn commented 3 years ago

I am expecting that the default behavior for @NotNull should be as nullable=true, otherwise, the bean validation does not work, because the field will always be not null

zapov commented 3 years ago

The default behavior of DSL-JSON is to throw validation exception for null values on properties marked with NotNull. It seems wrong that it behaves any different than this by default. This ones are recognized by default: https://github.com/ngs-doo/dsl-json/blob/master/java8/src/main/java/com/dslplatform/json/processor/CompiledJsonAnnotationProcessor.java#L67

Actually what do you mean nullable = true for NotNull You want DSL-JSON to ignore nullable annotation and let the property through so you can do your own validation?

zapov commented 3 years ago

It seems what you want is being able to configure the list of signatures in those lookups. That seems fair, but its not currently supported out of the box.

To get that behavior you will have to copy this annotation processor class and remove the signatures from there.

hellnn commented 3 years ago

Yes, there is java validation api, that generates errors when validating beans

zapov commented 3 years ago

Ok, I'll keep this in mind when releasing next version. But I don't think that will be soon.

hellnn commented 3 years ago

Thank you, I've found a workaround for my case so far

zapov commented 1 year ago

There is now new option to specify this behavior: https://github.com/ngs-doo/dsl-json/commit/c6b790e8cb3446fc53fee17e04c647b7fb2f0001

zapov commented 1 year ago

v1.10 released