FSTObjectOutput is stored in a threadlocal. And before every usage FSTConfiguration sets itself inside FSTEncoder (see FSTConfiguration#getOut). That's why FSTEncoder have to reset cached ClazzNameRegistry - registry depends on configuration. Registry have to be rewritten when configuration was changed.
In the test I reproduce this bug. There is two FSTConfiguration instances. Timestamp.class isn't registered in the second configuration. But ClazzNameRegistry wasn't reset and FST serialize value like class is registered.
The same code is in FSTStreamDecoder.
(BTW, FSTStreamDecoder is only one implementation of FSTDecoder, where setConf method is correct. Am I right, that FSTJsonDecoder/Encoder and FSTBytezDecoder/Encoder also need this fix?)
Maybe I should add some description.
FSTObjectOutput is stored in a threadlocal. And before every usage FSTConfiguration sets itself inside FSTEncoder (see FSTConfiguration#getOut). That's why FSTEncoder have to reset cached ClazzNameRegistry - registry depends on configuration. Registry have to be rewritten when configuration was changed.
In the test I reproduce this bug. There is two FSTConfiguration instances. Timestamp.class isn't registered in the second configuration. But ClazzNameRegistry wasn't reset and FST serialize value like class is registered.
The same code is in FSTStreamDecoder.
(BTW, FSTStreamDecoder is only one implementation of FSTDecoder, where setConf method is correct. Am I right, that FSTJsonDecoder/Encoder and FSTBytezDecoder/Encoder also need this fix?)