directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: ServerEntry serialization issues
Date Tue, 15 Jan 2008 19:30:05 GMT

On Jan 15, 2008, at 8:32 AM, Emmanuel Lecharny wrote:

> Hi,
> while dealing with some tricky serialization code, I faced some  
> little problem... We currently can only serialize a straight  
> ServerEntry without its reference to the registries, but then when  
> we need to deserialize the ServerEntry, we will have to add those  
> registries after the entry has been read from disk (or memory).
> This is a little bit cumbersome, as it forces the developper to  
> remember to do so, otherwise, he won't be able to modify the entry.
> Another problem I'm facing is that Mitosis currently use Entry to  
> communicate between two servers. For the same obvious reason, there  
> is no mean to save the registries in the serialazed form of the  
> ServerEntry, so I'm just wondering if we should not simply use the  
> LDIF Entry structure to exchange entries ?
> Right now, I will translate ServerEntry to Attributes and back,  
> until we have a clear vision of what we need to do.
> wdyt ? Any other better idea to solve these problems ?

I think this really raises the question as to whether including the  
registries in ServerEntry is completely wise....

One strategy to make them serializable would be to define a new class

public class ObjectInputStreamWithRegistries extends ObjectInputStream {
private final Registries registries;

public ObjectInputStreamWithRegistries(InputStream in, Registries reg) {
     this.registries = reg;

public Registries getRegistries() {
     return registries;

and in ServerEntry

private void readObject( in)
      throws IOException, ClassNotFoundException {
     this.registries = ((ObjectInputStreamWithRegistries) 

Obviously this needs a bit more error checking and requires people to  
use a special ObjectInputStream.

david jencks

> -- 
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message