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.