but, It cannot work. I can’t understand this comment. Change message classes by adding the marker interface and possibly needed annotations as described in Serialization with Jackson.
How can old cluster deserialize java/jackson in 2nd step? Please explain in detail.
I don’t think you should have "com.my.MyMessage" = java in the bindings in the first place because that is already covered by java.io.Serializable binding.
In 2nd step there will be no Jackson serialization/deserialization because MySerializable has not been added to the bindings (for serialization/toBinary) yet.
In 3rd step the new cluster nodes will start using Jackson for serialization/toBinary and when those messages are received the old cluster nodes are prepared to deserialize those given the changes in 2nd step.
When writing this I realize that we might have missed one thing in that description. 2nd step might need config:
is needed in step 2. Replace com.myapp with the name of the root package of your application to trust all classes. This is needed for Jackson deserialization when the serialization-bindings isn’t defined.
The whitelist can be removed in step 3, because then it’s defined in the serialization-bindings.
Hello @patriknw ,
sorry for digging out such old thread :-) step 2 “adding the marker interface” would already break java serialization for case classes which did not yet have the explicit SerialVersionUID annotation, right?
So step 1 should include “add SerialVersionUID to all message classes that are candidates for adding the marker interface in step 2”.
Correct?