Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 72.14.220.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=brhi4BJVgnCJrr7XgfX+L4eeAUTNxL2OHzyPSY8kbwe8T4BDzDXzQ+OQOJ+ZzQAtGL6F2lz+CHtHxL3JMFA468RQwD1u+qhXf8sYbB9UbZ7zGlgWbudlMnHyBMjAXsDqrFW6/bqUf0BFQaDH88YOafO/o8BtURsa8PRwZyRQJ1s=
Message-ID: <4776EE36.8020605@gmail.com>
Date: Sun, 30 Dec 2007 02:02:46 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: ServerEntry : one more step...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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