You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
public class Employee {
private String name;
private boolean nameSpecified;
private LocalDateTime birthday;
private boolean birthdaySpecified;
private String jobTitle;
private boolean jobTitleSpecified;
public String getName() {
if (!nameSpecified) {
throw new IllegalStateException("The property `name` is not specified");
}
return name;
}
public void setName(String name) {
this.name = name;
this.nameSpecified = true;
}
public LocalDateTime getBirthday() {
if (! birthdaySpecified) {
throw new IllegalStateException("The property `birthday` is not specified");
}
return birthday;
}
public void setBirthday(LocalDateTime name) {
this.birthday = birthday;
this.birthdaySpecified = true;
}
public String getJobTitle() {
if (!jobTitleSpecified) {
throw new IllegalStateException("The property `jobTitle` is not specified");
}
return jobTitle;
}
public void setJobTitle(String jobTitle) {
this.jobTitle = jobTitle;
this.jobTitleSpecified = true;
}
@Override
public String toString() {
StringBuilder builder = new StringBuilder();
builder.append("Employee");
String separator = " {";
if (nameSpecified) {
builder.append(separator).append("name=").append(name);
separator = ", ";
}
if (birthdaySpecified) {
builder.append(separator).append("birthday=").append(birthday);
separator = ", ";
}
if (jobTitleSpecified) {
builder.append(separator).append("jobTitle=").append(jobTitle);
}
return builder.append("}").toString();
}
}
It's obvious that the Employee object is NOT POJO, some properties are not specified or set to null are totally different.
This is popular design in ORM
Unspecified: The value of the property is unknown
Null: The value property is known, it has no data.
For example, since hibernate3, it is used by lazy scalar properties.
This is actually a way to make objects dynamic while retaining the advantages of strongly-typed language.
Clearly, the default Jackson cannot serialize/deserialize this object, and Jackson's behavior needs to be overridden, unspecified properties must be skipped (like the logic of toString).
Properties that are not specified need to be ignored by Jackson, which is highly similar to the requirement of @JsonFilter, with the only difference being that the filtering rules are not fixed but independent for each object.
I tried to solve this problem by registering custom Serializer and Deserializer through a custom Jackson Module. However, my custom read/write strategies are not as comprehensive as the standard Jackson behaviors, and inevitably break some advanced Jackson features such as @JsonAlias, @JsonValue, inheritance, and polymorphism.
Therefore, I need to implement dynamic object filtering without breaking any advanced Jackson features, as if each object had its own @JsonFilter.
Is there an elegant way to achieve my requirement?
Actually, the class mentioned above is a logical equivalent extracted from my own framework, which is very simple and suitable for discussion as a standalone problem. In my framework, to handle such dynamic objects, I custom-defined ImmutableSerializer and ImmutableDeserializer to handle Jackson serialization/deserialization of dynamic objects. However, my approach cannot accommodate all advanced Jackson features, and users have reported bugs related to certain advanced Jackson features being broken over the past two years, which has been bothering me a lot. Though I can use my way to let each broken features compatible with original behavior of jackson, there seems to be no end in sight.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Let's assume there is a class like the following:
It's obvious that the Employee object is NOT POJO, some properties are not specified or set to null are totally different.
This is actually a way to make objects dynamic while retaining the advantages of strongly-typed language.
Clearly, the default Jackson cannot serialize/deserialize this object, and Jackson's behavior needs to be overridden, unspecified properties must be skipped (like the logic of
toString
).Properties that are not specified need to be ignored by Jackson, which is highly similar to the requirement of @JsonFilter, with the only difference being that the filtering rules are not fixed but independent for each object.
I tried to solve this problem by registering custom Serializer and Deserializer through a custom Jackson Module. However, my custom read/write strategies are not as comprehensive as the standard Jackson behaviors, and inevitably break some advanced Jackson features such as @JsonAlias, @JsonValue, inheritance, and polymorphism.
Therefore, I need to implement dynamic object filtering without breaking any advanced Jackson features, as if each object had its own @JsonFilter.
Is there an elegant way to achieve my requirement?
Actually, the class mentioned above is a logical equivalent extracted from my own framework, which is very simple and suitable for discussion as a standalone problem. In my framework, to handle such dynamic objects, I custom-defined ImmutableSerializer and ImmutableDeserializer to handle Jackson serialization/deserialization of dynamic objects. However, my approach cannot accommodate all advanced Jackson features, and users have reported bugs related to certain advanced Jackson features being broken over the past two years, which has been bothering me a lot. Though I can use my way to let each broken features compatible with original behavior of jackson, there seems to be no end in sight.
Beta Was this translation helpful? Give feedback.
All reactions