ServerEntry : one more step...

[Emmanuel Lecharny <el...@gmail.com>]

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 ...

Commit is for tomorrow.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: ServerEntry : one more step...

[Emmanuel Lecharny <el...@gmail.com>]

David Jencks wrote:
>
> On Dec 29, 2007, at 5:02 PM, Emmanuel Lecharny wrote:
>
>
> 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.
Well, I'm afraid that the two API are insanely different ;)

The main issue is that we need more informations to build an entry than 
we were for Attributes : a DN and accdess to the registries. This make 
the automatic conversion virtually impossible.

The second point is that the new API is not stable yet, and this manual 
conversion is the best way to discover the small little missing bolts 
and nuts. (I wish they don't build planes or car this way !!!)

Last, not least, as I already told Alex, I like to do such tasks 
manually because it's the best way to 'see' what's inside the server, 
and helps to discover bad code or bad formatting. I'm fixing a lot of 
warnings this way. Of course, this is error prone, but not that much.

I'm a little bit old school, too :) I still remember the "printf" 
debugger times !

Thanks David !
>
> hope this helps...
> david jencks
>
>>
>> Commit is for tomorrow.
>>
>> ----
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>
>


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: ServerEntry : one more step...

[David Jencks <da...@yahoo.com>]

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
> www.iktek.com
> directory.apache.org
>
>