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