directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Question regarding FilterVisitor implementation
Date Sun, 10 Sep 2006 15:08:55 GMT
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>> Strange. From what I understand of the code - and sure Alex can give 
>> you a better explanation -, there is a 'visit' method in the 
>> NormalizingVisitor which is applied to all the attributes found in a 
>> filter into the NormalizationService.search(). It seems that for some 
>> attributes, like ObjectClass and cn, there is no transformation to an 
>> OID form. I don't know if it's a bug, or if the search fails because 
>> of this behavior, but definitively this need some further investigation.
>>
>>>
>>> For instance in "(&(objectClass=*)(sn=Amos)(cn=Tor*))" for the first 
>>> two operands within the AND expression, the OID is returned,for the 
>>> third one "cn". I have created a work around with the help of 
>>> AttributeTypeRegistry. Lucky me -- it is available in interceptors. 
>>> But I am curios: is it a bug, that sometime not the OID but the (a) 
>>> attribute name is returned?
>>
>> I really don't know, but I can reasonably say that it should not work 
>> the way it does :) Let's open a JIRA !
>>
> Thanks for your reply, Emmanuel! The strange thing is, that even for 
> "cn", the OID is returned, if I use the eq (=) operator in the leaf. 
> Only if I use a substr expression like "cn=Tor*", the name "cn" is 
> returned.
> 
> I'll try to isolate this problem and will file a JIRA issue, then.


Sorry for taking so long to respond.  I've been hard to reach lately.

But yes this sounds like a bug.  Something I can play around with and 
isolate using some unit tests.

Alex

Mime
View raw message