Most objects returned by the Unified API support object
serialization as per java.io.Serializable
for persistent storage. While you
should normally keep all persistent CMS data in the content and workflow repositories,
serialization might be appropriate for short term storage, for example when maintaining
conversational state in a web application.
Serialization itself requires no additional setup. Mutable objects will write their identity
to the ObjectOutputStream
, while values write their value. One piece of
information is lost, however: the connection is not written to the stream. This is because a
connection maintains a complex dynamic state and because it keeps security credentials that
should not be externally accessible.
Therefore, you have to provide a connection when deserializing a Unified API object. This is done by registering a connection at the class DefaultConnection. You can register a connection for the entire JVM. However, CoreMedia recommends that you register a connection specifically for the thread that deserializes the objects. For an example, see the following code fragment:
CapConnection old = DefaultConnection.setLocal(myConnection); try { object = objectInputStream.readObject(); } finally { DefaultConnection.set(old); }
Here a specific connection myConnection
is set before accessing the stream. By
resetting the connection after deserializing, you avoid unexpected side effects to calling
code.
Besides the connection, also its sessions, its repositories, and its services cannot be
serialized. Moreover,
Blob
objects do not support serialization. While blobs provide a value semantics, storing them in
the object stream would be undesirable due to their size, so that a write of a blob normally
indicates an error. If you want to serialize blobs, you can do it manually by converting the
blob to a byte array during a writeObject
method.
Caution | |
---|---|
Serialization is not recommended for long term storage. Future CMS releases might make incompatible changes to the stream format. |