Java plugin supports serializing/deserializing class information in callback context , this plugin doesnt support that today.
Use case, related to #243. Say I want to store a datetime.datetime object. Right now it gets returned as a string, so the next time I use it when I am called back, it comes across as a string not as an original datetime object.
I confirmed this on the handler side by printing out a ProgressEvent post serialization.
So if we attempt to store any non-primitive type its replaced with a string representation and no way to get back to it. This requires handler authors, if they want to use complex types, to do their own marshalling.
Java plugin supports serializing/deserializing class information in callback context , this plugin doesnt support that today.
Use case, related to #243. Say I want to store a datetime.datetime object. Right now it gets returned as a string, so the next time I use it when I am called back, it comes across as a string not as an original datetime object.
I confirmed this on the handler side by printing out a ProgressEvent post serialization.
Received on the
cfn test
side for contract testing:So if we attempt to store any non-primitive type its replaced with a string representation and no way to get back to it. This requires handler authors, if they want to use complex types, to do their own marshalling.