directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ServerEntry] We may need our own JDBM code base
Date Sat, 09 Feb 2008 15:20:11 GMT
Hi Emmanuel,

On Feb 7, 2008 8:35 AM, Emmanuel Lecharny <> wrote:

> Hi guys,
> I'm now pushing the modifications to the backend. Entries will be stored
> as ServerEntry serialized data, instead of serialiazed Attributes. This
> will have some impacts :
> - The MasterTable won't be compatible with the previous version (1.X and
> 1.5.1)

That's fine.  1.5.x is an experimental branch where we heavily induce change
and our users are aware of this policy (at least we can hope).

> - We will have to modify the way data are serialized, using some other
> instance of Serializer classes (this is an Interface declared in the
> JDBM package, which is used internally by JDBM)
> - As JDBM serialize the Serializer into the files on disk, and as our
> new serializer needs some reference on Registries, this is a dead end :
> the restored Serializer won't contain any reference to the registries
> The last point is blocking. I don't know why JDBM has to store a
> reference to the serializer, but the BTree class use it :
> BTree
> ...
>    public void readExternal( ObjectInput in )
>        throws IOException, ClassNotFoundException
>    {
>        ...
>        _valueSerializer = (Serializer) in.readObject();
> Here, we need to inject the registries, otherwise the serializer won't
> be initialized correctly, leading to NPE all over the server. The BPage
> class use this _valueSerializer to serialize and deserialize data
> (BPage implements the Serializer interface) :
> ...
>                        if ( serialized != null ) {
>                            bpage._values[ i ] =
> _btree._valueSerializer.deserialize( serialized );
> ...
> So I suggest we define a new project with JDBM sources, and fork from
> the existing base to have our own. That will allow us to bypass this
> limitation.

Absolutely.  +1

JDBM is dead at SF anyway so I don't see very many changes taking place
there.  However you might want to look at the differences between the
1.0tag for JDBM and HEAD.  There was a fellow there that tried to
solve these
issues of serialization and he was given committership to do so.  I don't
know if he actually achieved his goal.

Regardless I support this move to fork JDBM but I think we should let the
JDBM people know and we should figure out which version to grab and be able
to track what changes may occur on SF.

Hopefully the folks at SF can come here to Apache and this project could be
maintained somewhere here at Apache.  I'm thinking more like commons -
definitely not here at Directory.

Code is a responsibility :(.

> Any other solution in mind ?

No you have the best idea here.


View raw message