Hi,
as usual, trying to fix a bug can leads to many others...
1) Lookup operation usage
first, we have to consider that Lookup has many meanings, depending on
the context.
- JNDI : the Lookup operation returns a Java object
- LDAP : there is nothing such as a Lookup operation in LDAP, but we
have one in out API
One more problem is that JNDI has a getAttributes() operation which is
what our Lookup operation does in our API.
Last, not least, inside the server, a lookup is done when we want to
fecth an entry with *all* its attributes.
This is just a mess...
Here is what I suggest, feel free to provide your opinions :
- lookup operation will remain in our API, and it will behave the exact
same way than a search done with a BASE_OBJECT scope, (objectClass=*)
filter. A user can pass a list of requested attributes, plus the special
values '+', '*' and '1.1'. The parameter 'TypesOnly' can also be used.
Controls are accepted
- inside the server, we will rename the operation to fetchEntry(), and
it will bypass all the interceptors (we will just call
nexusPartition.fetchEntry( DN )).
- the JNDI layer we provide will map getAttributes to lookup, and the
JNDI lookup method will still unmarshall the result to a Java instance.
2) Search Operation execution
Right now, the way we process a search is that we create a cursor, add
some filters to this cursor, and then loop on the cursor, fetching a
candidate from the backend (which will evaluate the entry against the
filter), and filtering the enry before it returns it.
So far, so good except that it does not work for a filter done on
collective attributes (like '(c-l=Paris)' will not match any result).
This is because in the searchEngine, the entry we are processing does
not have *yet* the collective attribute added.
One way to fix this would be to remove the collective attributes check
from the filters, and to filter the entry higher (in a filter added to
the cursor). Obviously, it will come with a cost, unless we add some
index for collective attributes.
3) Lookup processing
Depending on the way we do a lookup from outside of the server, we will
have a different way to process it :
- if we go through the ServerContext.getAttributes() method (JNDI API),
we directly call the operationManager.
- if we use out API, we first go through the CoreSession instance, which
calls the OperationManager.
The problem is that we can't filter the attributes if we do a lookup
through our API, when we can with the JNDI call, because we filter the
unwanted attributes in serverContext.
My first thought was to modify the ServerContext to call the CoreSession
which itself calls the OperationManager, and add the filtering of
Attributes in CoreSession, but sadly, this is not possible because in
this case, we lose the controls.
Here is what I suggest to fix this situation :
- make the ServerContext call CoreSession
- add the filtering of attributes in CoreSession
- modify the Lookup operation in our API to pass the controls
That's pretty much it with the problems I currently have...
thoughts ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
