Emmanuel Lecharny wrote: > Alex, > > just a quick status before I hit the sack. > > Server is running again. Fixes where easy. > > 1) Atm, I have a clear problem when trying a search at the top level, > with scope=ONE LEVEL : it returns everything.
Yeah I'll have to start debugging the scope based search constraints. It's not an easy peice of code. > > 2) I also have a problem with OID map: I need to get the <OID, > Normalizer> couple, instead of <whatever alias, Normalizer> to store > the OID into the normalized AttributeType of each RDN (as we will work > with OID internally, not with alias). If we don't do that, we may have > missed searches, I'm afraid. The method to modify is : > org.apache.directory.shared.ldap.name.LdapDN.rdnOidToName() in > shared-ldap. > Here is the code (I've prepared a String oid variable to store the > oid, currently, it stores the type) > ... // Should > get the OID, not the type > String oid = type; > ... > around line 1300 This is a big problem. Currently the LdapDN class is rightfully in the shared-ldap package. To extract the OID of an attribute in the server by attributeType alias we use the OidRegistry. This however is a server schema object in the core. Naturally I'm sure you see why I don't want to create a dependency here. Perhaps I can give you another map. An alias to OID map generated from the OidRegistry. What do you think? > > 3) I think we should have two versions of codec : one for server, and > one for client. The problem is that we do useless conversions when > retruning results to the client. For instance, the SearchResultEntry > will contain an objectName, and this should be a String, not a LdapDN, > if we use it on the server side. Ok, I know, not a big deal... Let's > keep this somwhere and put a little flag above it (a JIRA flag) and we > will go back to it in july :) I don't know if I agree on this. But it is something to consider. I just don't have the brain power to contemplate this :(. Alex
