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
