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 <email@example.com
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 unfortunately.
- 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 out.
- 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
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
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 before.
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 ?)