On Thu, Feb 24, 2011 at 11:12 PM, Emmanuel Lecharny <[email protected]> wrote: > 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 > Value > BitString > OID > Csn > [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 : > ------------------------ > LdapPrincipal > ChangeLogEvent > ReplicaEventMessage > ParentIdAndRdn > (Entry) -> DefaultEntry, ImmutableEntry, ClonedServerEntry, > ClonedServerEntrySearch > (EntryAttribute) -> DefaultEntryAttribute > (Modification) -> DefaultModification > (Value) -> [AbstractValue] -> {BinaryValue, StringValue} > LdifEntry > Ava > Rdn > > > 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. > having a single serializer class will force dependency on the packages that are not interested by a user trying to use just a portion of API for e.x if I want to customize a particular module and only interested in serializing Entry classes the suggested serializer class will require ldif module too, even if it is not required > The target is to be able to finish the Dn/Rdn/Ava cleanup, for what it > worth... > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
-- Kiran Ayyagari
