-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add @JsonIncludeProperties(propertyNames)
(reverse of @JsonIgnoreProperties
)
#1296
Comments
@JsonInclude(propertyNames)
if added as annotations@JsonIncludeProperties(propertyNames)
(reverse of @JsonIgnoreProperties
)
what is the solution? finally |
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. |
@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 |
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. |
Ok. I guess I understand what you are asking, but not necessarily what the benefit would be. For what it is worth you could implement something like this by sub-classing 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. |
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 I'm going to open an issue to support whitelisting. Thank you for your work and support! |
@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. |
It would be a nice addition for those who need to expose public APIs. |
Would love this as well. |
Agree, this would be very useful for exposing public APIs. |
Anyone with an itch is totally free to work on this. |
Yes, |
I support this feature as well |
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. |
I also need @JsonIncludeProperties(propertyNames) @Entity
public class Customer {
...
private SalesMan salesMan;
...
@ManyToOne
@JsonIncludeProperties({"id", "name"})
public SalesMan getSalesMan() {
return salesMan;
} |
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. |
This will be very useful if implemented. Gonna help us to avoid all those custom serializer classes. |
This will come very handy especially for annotating JPA associations |
Would really like this feature! It would help clean up some of my models significantly. |
I echo the feature request. |
@JsonIncludeProperties(propertyNames) is a must-have IMO. |
Need this for a usecase that involves isolating PII in the POJO. While this is possible with |
I agree; this feature will be extremely useful. |
Please!!! |
+1 |
1 similar comment
+1 |
+1. This will be very useful. |
+1 |
1 similar comment
+1 |
At this point it has been established that users would find such annotation/property useful; locking comments as further +1s are just noise. |
Being worked on as #2771, planning to get included in 2.12. |
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. |
Was included in 2.12.0; outlined as one of 5 "Most Wanted" new features. |
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).
The text was updated successfully, but these errors were encountered: