When creating the serialized flowstates, it stubs all the application context beans and script function objects, thus minimizing the size of the serialized state. When deserializing, it will reattach the deserialized state to stubbed objects, resolving them by name. This way, it is allowed to have references to application context objects in the reachability graph of the serialized state, as they will get stubbed and resolved correctly. It is however strongly not advised to have references to any other external objects in the running scripts or objects referenced by them, as they will either fail serialization, or - lacking stubbing - cause duplicate instances to be created upon deserialization.
As a safety feature, the MD5 fingerprint of each function's code that is on the continuation's call stack is stored along with the continuation, and matched upon retrieval, with an exception being thrown if they don't match. In case that the underlying script changed since the continuation last run (i.e. because you restarted the servlet context and reloaded a changed script) this causes clean fast failure, instead of unpredictable behavior caused by invalid return addresses in the continuation stack frames.
The class supports setting a {@link org.szegedi.spring.web.jsflow.codec.BinaryStateCodec}, enabling pluggable compression, encryption, and/or digital signing of the serialized state. This is most useful with the {@link org.szegedi.spring.web.jsflow.ClientSideFlowStateStorage} subclasswhere the client is entrusted with storing the flowstates, so you might wish to ensure they're resistant to tampering. @author Attila Szegedi @version $Id: AbstractFlowStateStorage.java 104 2009-12-01 18:44:14Z szegedia $
| |