directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject API cleanup update
Date Thu, 24 Feb 2011 17:42:21 GMT
Hi guys,

just a quick heads up about what I'm working on.

Currently, I'm removing all the useless Serializable implementation. I 
think we went anal by declaring a lot of classes to be Sezializable, 
when there is no reason for those classes to be serialized in any way. I 
have removed the implementation for those classes :
(DirectoryServiceOperation) -> ChangePassword, GetCatalog, GetPrincipal
[Permission] -> {ItemPermission, UserPermission}
[UserClass] -> {AllUsers, ParentOfEntry, Subtree, ThisEntry, 
[NamedUserClass] -> {Name, UserGroup}}
(SchemaObject) -> [AbstractSchemaObject] -> {AttributeType, 
DITContentRule, DITStructureRule, LdapSyntax,
     [LoadableSchemaObject] ->{LdapComparatorDescription, [Normalizer] 
-> {…}, NormalizerDescription,
     [SyntaxChecker] -> {…}, SyntaxCheckerDescription}, MatchingRule, 
MatchingRuleUse, NameForm, ObjectClass}

(xxx) are interfaces, [xxx] are Abstract classes.

I still have the LdapComparator and the classes extending it 
implementing Serializable, because JDBM serialize some comparators. I 
trully think it's a confusion we should get rid of. There is no need to 
serialize SchemaObject elements into the backend, when we just want to 
now which comparator to use. Up to a point, the Table knows which kind 
of SchemaObject it stores, and can grab the associated comparator using 
the SchemaManager. However, this is an area I'm not comfortable with so 
I keep those classes implementing Serializable.

I'll do the same work for Externalizable, here are the classes 
implementing this interface :
Externalizable classes :
(Entry) -> DefaultEntry, ImmutableEntry, ClonedServerEntry, 
(EntryAttribute) -> DefaultEntryAttribute
(Modification) -> DefaultModification
(Value) -> [AbstractValue] -> {BinaryValue, StringValue}

AFAICT, all of them have to be externalizable, because they all get 
serialized at one point of another in the server (either in the backend, 
or in the changeLog)

However, I do think that depending on the default serialization process 
is a *bad* thing : it's costly, and can be avoided. We cureently have a 
few static classes (DnSerializer, RdnSerializer, AvaSerializer, 
EntrySerializer) which handle the optimal serialization, we should add 
some more.

Alex suggested to design a single Serializer class which can handle all 
those serialization/deserialization, I'm 100% with him on that.

The target is to be able to finish the Dn/Rdn/Ava cleanup, for what it 

Emmanuel Lécharny

View raw message