directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ServerEntry] problems ...
Date Sun, 06 Jan 2008 19:12:36 GMT
This is why we have an ServerEntryFactory concept now.  You ask this service
to give you a server side entry.  And that entry should be equipped with a
means to resolve registries to perform the checks it needs.

On Jan 5, 2008 10:39 AM, Emmanuel Lecharny <> wrote:

> Hi guys,
> the more I'm using the new API, the more I have problems with the choice
> we have made to put the registries into each ServerEntry instances.

We talked about this and the factories that instantiate entries.  You need
schema information no matter what right to avoid the anomolies that we have
been trying to get rid of no?  The other option is to still access the
registries but to use those ugly AttributeUtils methods with attributeTypes
looked up from registries.

The bottom line is we need to delegate the creation of server entries to
some service like this ServerEntryFactory whose task is to just create new
entries that have what they need without the user having to know the
details.  The registries are a hidden implementation detail.  Later on I
want to avoid having a hard reference to registries as well.  Perhaps the
ServerEntry instances have a reference to some kind of schema service.  The
more of these implementation details we hide the better we will be as we
move to other containers.

> - we have to gain access to the registries all over the code (not that
> much a problem, but ...)

We would have to anyway.  I don't think there is an alternative

> - in some cases, it becomes to be tedious, because the registries might
> not have been initialized ...

Well we are running into some chicken and egg problems but I have some ideas
on how to fix these problems you're now dealing with.  We can fix them
easily.  I'll try to keep this email short for now but perhaps we can touch
base later tonight.

> - if the registries (and especially the AttributeType and OID
> registries) are not setup correctly, you get some nasty error when
> executing the code.

OK this sounds like something is going wrong.  Let's touch base and talk.

> - as we have to initialize the server, and the system partition, we are
> declaring a contextEntry in the server.xml file. As a consequence, we
> need a new ServerEntryPropertyEditor to make Spring happy. But then, we
> have no registries initialized at this point : boooom....

This can be fixed easily after our conversations yesterday I had some nice
alone time to figure out a better approach.  Let's touch base and figure it

> - from the user perspective, having to pass a registries each time he
> creates a new entry is boredom

We don't need to do that. We just need to ask that factory for new
ServerEntry instances.

> - and from the internal logic point of view, we are doing some kind of
> surface checking when the Normalizer and Schema interceptors will do
> some more.

Don't know what this means exactly.

> At this point, I'm just wondering if this is such a good idea to load
> the registries into a ServerEntry. I think it would be better to add a
> simple method to the class, check( Registries ), which will be
> responsible to do any kind of control we want (are the attributetype
> correct, etc).

Branch out and give it a try.  For now I recommend you commit what you have
even if it is broken into the bigbang.  I would like to take a look at it.
We have the trunk now so there is no need to worry about messing people up.
Let's just work together on this problem - I'm sure we'll figure it out and
everything will be just fine as we have collaborated this way many times

> We may also do that in the Normalization interceptor, as this is the
> first one to be called.

Starting to loose you now with my MTV attention span.  Sorry it's my fault.

> The drawback is that we will have to call two methods instead of a
> constructor when creating a ServerEntry, but the big advantage is that
> the ServerEntry might pretty well become a common class with the
> Cliententry (I see no reason why those two classes would be different if
> we remove the inner checks against the Registries ?)
> wdyt ?

Let's explore these ideas issues and problems as I expressed similarly
inline.  Feel free to just commit and we can start looking at this problem


View raw message