directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Serialization/deserialization questions
Date Fri, 25 Feb 2011 13:57:04 GMT
On Fri, Feb 25, 2011 at 2:22 PM, Emmanuel Lecharny <> wrote:
> Hi guys,
> I'm reworking all the serializations for the base objects we are
> manipulating. I have a few questions and I'd like to get you opinion.
> The base idea is to get rid of all the Externalizable/Serializable
> interfaces, and to provide our own helper classes to serialize the objects
> we have to write down the disk. The rationnal is that we avoid the cost of
> writing the useless java class informations, keeping the written objects as
> small as possible, and the process as fast as possible.

Could you provide some of the problems that you encountered due to the
use of the Externalizable/Serializable intefaces in some of these

> Q1 : Do we have to store a version number into the written data ?


> Q2 : I'm going to inject the SchemaManager in all the deserialized data (it
> can be null, if the SchemaManager has not been created). Do you think it's a
> problem ?

We can have separate serialization services that have a handle on the
SchemaManager. These services can use schema information to handle
their task of [de]serializing. However there are some entities that
need access to schema information in order to conduct some operations
like Entry.add( attribute ). How we handle access to schema
information while they perform schema checks is another matter which
we need to discuss.

Perhaps a schema aware Entry wrapper can access this information
leaving the simple Entry free to do as it likes while it intercepts
calls and conducts schema live checks before delegating the call.
Things like this can also be handled automatically with byte code
manipulation. We can discuss this separately which would be involved.

> Q3 : In order to be able to create the object as it was when it was
> serialized, I'll create package visible only constructors, with all the
> needed parameters. Does it sounds the right approach ?

This will require the [de]-serializer to be in the same package. That
could present an issue with split packages if we want to make these
entities into services down the line. I'd go ahead and make the
constructors public for now.  Off the top of my head I cannot think of
a detriment to exposing these constructors but perhaps you have some
in mind?


View raw message