directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: ServerEntry : one more step...
Date Sun, 30 Dec 2007 02:14:50 GMT

On Dec 29, 2007, at 5:02 PM, Emmanuel Lecharny wrote:

> Hi,
> FYI :
> I have modified the getRootDSE operation to use only ServerEntry  
> into it. I thought it would be an easy task, as it's a very limited  
> operation, but I was plain wrong ...
> I would say first that I'm almost done : I still have one nasty  
> error in server-utils (all integ tests are now running).
> But I had to fight with many problems :
> - The rootDSE is initialized deep into the server, so it implied a  
> lot of cleanup (like defining some new constants for each of the  
> elements stored in the rootDSE)
> - I also changed all the operationContext to store the Registries  
> inside (it was quite boring, but went smoothly). As a consequence,  
> I had to modify a lot of interceptors to be able to get the  
> registries reference.
> - As those operationContexts are used in places where we don't have  
> access to the registries, I had to add a lot of parameters to many  
> functions.
> - The ServerEntry/ServerAttribute API appeared to be far from  
> perfect :) Lot of bugs, side effects, and missing operations. This  
> is still a work in progress
> - The setContextEntry() method has also been changed to handle a  
> ServerEntry : this was _painfull_, as the addition of a partition  
> may be done _before_ the registries initialisation... As  
> ServerEntry needs an access to the registries, I finally decided to  
> add a setContextAttr() method, for this very special case : we use  
> an Attributes which will be transformed to a ServerEntry later,  
> when the registries is set. I know, this is an ugly disgusting  
> hack ...
> - Another dirty hack is the way we handle the NamingContexts. For  
> some reasons, we store an empty NamingContext (a null value) which  
> is not used, I guess (or is it for the rootDSE ???), and this has  
> some very strange and not funny side-effects. It has to be reviewed.
> Right now, after a long long day of coding, i'm fed up. I still  
> have to add a new set of methods to the ServerAttribute class : we  
> have 'put', but we also need 'add'. The 'put' method will replace  
> the existing attribute/value with a new one(s), when the 'add'  
> method simply add new attribute/value.
> The API needs some cleaning and polishing, but I must say that we  
> are now close to an usable API. I didn't found any big breach in  
> it, except that the fact we need to pass a Registries/ 
> AttributeTypeRegistry each time we want to create a new ServerEntry  
> or a new ServerAttribute is more than painfull. It would be much  
> better to have factories for such tasks...
> So far, 133 references to Attribute, Attributes, AttributeImpl and  
> AttributesImpl have been removed from the server... More or less  
> 2.77% of all the references ! The pace is a little bit too slow, as  
> it will takes 68 days and a half to get rid of all those classes !  
> (let say 40 days, as 40% of those references are in tests...).  
> January won't be funny ...

I'm afraid I haven't been following this development closely but if  
the new apis are reasonably close to the old ones you might be able  
to automate a lot of the conversion with IDEA's refactoring tools...  
e.g renaming Attribute to ServerAttribute (in the right package) then  
changing method names and signature to match your new ServerAttribute  
method names/signatures.  Once they line up you can put your  
ServerAttribute class back.  I don't know how much of this you can do  
in eclipse.

hope this helps...
david jencks

> Commit is for tomorrow.
> -- 
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message