Hi Peter,
We had some discussions about that in the past. There are actually other
implementations of the OpenCMIS interfaces (not part of Apache
Chemistry) that can not and need not be serializable. We don't want to
force them to do something crazy just to implement the OpenCMIS interfaces.
The OpenCMIS classes have been designed to be serializable from the
start to support HTTP sessions. Casting to Serializable is safe now and
will be safe in the future -- even though it might feel weird.
What surprises me is that creating a session takes several seconds.
Connecting to a Alfresco server on a local network takes about 100ms. If
it takes significantly longer then there is something wrong...
Florian
On 01/06/2011 23:35, Peter Monks wrote:
G'day everyone,
Creating an org.apache.chemistry.opencmis.client.api.Session is quite an
expensive operation (it typically takes several seconds), so I'm looking to
cache Session objects in a per-user cache in my client app so that I don't have
to recreate Sessions for every single interaction with the CMIS server.
Unfortunately the cache library I'm using requires that cached objects
implement java.io.Serializable, which Session does not. However the default
implementation class (org.apache.chemistry.opencmis.client.runtime.SessionImpl)
does in fact implement Serializable, allowing me the workaround of casting the
Session object to Serializable prior to adding to the cache. I'm not
particularly comfortable with this approach however, given that this seems to
be an implementation detail and not officially part of the contract for
Sessions.
Is there a compelling reason that Session doesn't implement Serializable? Is
this something that could be added (noting that this change is backwards
compatible)?
Thanks in advance,
Peter
