directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [ServerEntry] problems ...
Date Sat, 05 Jan 2008 15:39:40 GMT
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 have to gain access to the registries all over the code (not that 
much a problem, but ...)
- in some cases, it becomes to be tedious, because the registries might 
not have been initialized ...
- if the registries (and especially the AttributeType and OID 
registries) are not setup correctly, you get some nasty error when 
executing the code.
- 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....
- from the user perspective, having to pass a registries each time he 
creates a new entry is boredom
- 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.

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

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

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 ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message