Issue while deserializing a serialized object

Question

I have a kotlin data class, having a parameterized constructor, and a method which derives its output based on a property.
I have annotated this method with @JsonProperty so that its derived output can also be serialized to output JSON, as that was a requirement to me.
Now the issue arises when I try to deserialize this JSON, and it doesn't find any field for the derivedProp

Cannot construct instance of MyDataClass, problem: Should never call set() on setterless property ('derivedProp')

@JsonIgnoreProperties(ignoreUnknown = false)
data class MyDataClass(
   val boolProp: Boolean = true,
   val dataProp: DataProp = DataProp(),
   val mainProp: String? = null
) : Serializable {

   @JsonProperty
   @Suppress("unused")
   fun derivedProp(): List =
      someLogicOnMainProp(mainProp)

}

`val` defines immutable variables, so there is not setter for a val. Using `var` instead of `val` will fix the issue — , Dec 17 '18 at 10:15
issue is not for the 3 properties declared as val, it is for the forth one, which is created at the time of serialization due to the method derivedProp() — Vivek Gupta, Dec 17 '18 at 10:16
Possible duplicate of [Only using @JsonIgnore during serialization, but not deserialization](https://stackoverflow.com/questions/12505141/only-using-jsonignore-during-serialization-but-not-deserialization) — talex, Dec 17 '18 at 10:23

score 2 · Accepted Answer · answered Dec 20 '18 at 08:14

2

I solved this problem using the below property on @JsonProperty annotation:

@JsonProperty(access = Access.WRITE_ONLY)

answered Dec 20 '18 at 08:14

Vivek Gupta

2,534
3
15
28

score 0 · Answer 2 · answered Dec 17 '18 at 11:36

0

If you use a property instead of a function, you can still define a setter and just ignore it, when it's called. Not the prettiest solution, but should do the trick:

@get:JsonProperty
var derivedProp: List<Any>
    get() = someLogicOnMainProp(mainProp)
    set(value) { /* do nothing */ }

answered Dec 17 '18 at 11:36

Patric

1,489
13
28

This could be a workaround, but that will be at a cost of data redundancy at run-time, looking for a better solution :-) – Vivek Gupta Dec 17 '18 at 11:41
I don't quite follow, how will it be redundant? Instead of a function, you now just have a property. – Patric Dec 17 '18 at 11:44
because the data will be redundant (mainProp, and derivedProp) – Vivek Gupta Dec 17 '18 at 11:47
Well no it won't, because derivedProp is just a function you call on mainProp. It is not seperately stored... – Patric Dec 17 '18 at 11:54

Issue while deserializing a serialized object

2 Answers2