Jackson-databind: Add `@JsonIncludeProperties(propertyNames)` (reverse of `@JsonIgnoreProperties`)

[cowtowncoder]

In some/many cases it'd be easier to just name properties to include, reverse of @JsonIgnoreProperties. And similarly, it should be possible to define baselines by type as well as property overrides; and if ever we support inheritance-merging in class hierarchy, use similar merging strategies (merge vs replace).

NOTE: for this (2.12.0) implementation, no merging exists for class annotations -- sub-class definitions will always simply replace super-class/super-interface definitions. Similarly there is no way to specify inclusions using "ConfigOverride" system, although ignoral is possible. Latter would likely be relatively easy to implement (so feel free to file a follow-up request); former (annotation merging) is a more difficult ask (but likewise feel free to file a feature request).

[SUGE2016]

what is the solution? finally

[lukaszlenart]

It would be nice to have something like this where I can allow only a given class type hierarchy to be serializable/deserializable without defining all the properties.

[cowtowncoder]

@lukaszlenart Huh? I am not sure what you mean. Jackson can use fields as properties as well as getters; visibility level needed is configurable and just defaults to public.

[lukaszlenart]

Sorry for that :( What I meant is that I would like to allow serialise/deserialise only given classes, create a whitelist not blacklisting as you do now. Something like we have for XStream where only selected classes can be serialised/deserialised to/from XML.

[cowtowncoder]

Ok. I guess I understand what you are asking, but not necessarily what the benefit would be.
For common cases, starting with declared root type to deserialize (or type of instance to serialize), then following property types works well. So what would be the benefit of having to whitelist all types accepted? (assuming that would include "well-known" types like String, boolean/Boolean, all number + wrapper types, various Collection, Map types and so forth).

For what it is worth you could implement something like this by sub-classing isIgnorableType() of [Jackson]AnnotationIntrospector; it is method called to hande @JsonIgnoreType annotation.

Anyway: assuming idea would seem useful, maybe you could file another issue for it as it is distinct from this one. Implementation could be quite simple -- I assume registering a handler, with "simple" implementation (direct type lookup), would suffice.

[lukaszlenart]

I thought that I have posted an answer but it's gone :(

Anyway, having a whitelist is far safer than blocking the whole world. This gives more control and allows users precisely filter which classes can serialize/deserialize.

Your suggestion with overriding [Jackson]AnnotationIntrospector won't work because to keep backward compatibility at some point I have to call super.isIgnoreableType() which allows any type except those marked with @JsonIgnoreType.

I'm going to open an issue to support whitelisting.

Thank you for your work and support!

[cowtowncoder]

@lukaszlenart Safer, certainly, but also much more work for common cases where safety is not an issue (caller is trusted).

But just wrt this issue, I think it makes sense to separate what is requested here (which is not related to filtering by type), and then type restrictions -- while they may sometimes be used for some purpose, I assume more often they are not. There are legit reasons for both. So it's good to have separate issues for mostly separate discussions.

Thank you for opening the new issue.

[lukaszlenart]

It would be a nice addition for those who need to expose public APIs.

[Bas83]

Would love this as well.

[claytonfbell]

Agree, this would be very useful for exposing public APIs.

[cowtowncoder]

Anyone with an itch is totally free to work on this.
Would need to go in 3.0 (new annotations not allowed in patch release), in master.

[sunphy]

Yes,@JsonIncludeProperties(propertyNames) is very useful!

[nomadus]

I support this feature as well

[jhordies]

I would also love to see this implemented. It would be much safer especially when a developer would add a sensitive field in a referenced class without checking where it could be exposed through an api.

[ssamayoa]

I also need @JsonIncludeProperties(propertyNames)
Not only for sensitive fields but also for complex entity objects in which normally you don't need other than few properties, example:

@Entity
public class Customer {
...
private SalesMan salesMan;
...
@ManyToOne
@JsonIncludeProperties({"id", "name"})
public SalesMan getSalesMan() {
  return salesMan;
}

[cowtowncoder]

Yes, I think this is a highly wanted feature. I hope it could get implemented for 2.10. The big challenge is that by now all the code associated with discovery (and suppression) of properties is rather large and changes in place can easily cause problems in others. This is true especially here as we would be added a complementary system which counteracts main suppression-based mechanisms.

[yonetmen]

This will be very useful if implemented. Gonna help us to avoid all those custom serializer classes.

[nejeoui]

This will come very handy especially for annotating JPA associations

[Vynny]

Would really like this feature! It would help clean up some of my models significantly.

[anz000]

I echo the feature request.

[mihaiqc]

@JsonIncludeProperties(propertyNames) is a must-have IMO.

[farthVader91]

Need this for a usecase that involves isolating PII in the POJO. While this is possible with jsonignoreproperties, we would like to _exclude all by default_ to guard against future modifications to the POJO.

[AkashNeil]

I agree; this feature will be extremely useful.

[diegomors]

Please!!!

[Sdwz]

+1

[biwano]

+1

[backoon]

+1. This will be very useful.

[ghost]

+1

[PunKHS]

+1

[cowtowncoder]

At this point it has been established that users would find such annotation/property useful; locking comments as further +1s are just noise.

[cowtowncoder]

Being worked on as #2771, planning to get included in 2.12.

[cowtowncoder]

Merged; will do a bit of refactoring on naming and perhaps the way related pieces (ignore vs include sets) are handled. Will be included in 2.12.0.

[cowtowncoder]

Was included in 2.12.0; outlined as one of 5 "Most Wanted" new features.