[ https://issues.apache.org/jira/browse/DIRSERVER-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705645#action_12705645
]
Stefan Seelmann commented on DIRSERVER-1311:
--------------------------------------------
For the add operation the SchemaInterceptor class handles the case when the RDN attribute+value
isn't included in the entry's attributes and adds this attribute+value in that case.
On the other side, for the rename operation, the missing RDN attribute+value is added in the
JdbmStore class.
My question is: where is the better place to handle such stuff? I think it would be better
to handle it in the SchemInterceptor because when it is handled in the Store then it must
be re-implemented for each Store.
> Entry with an escaped comma in DN not found in searches with some filters
> -------------------------------------------------------------------------
>
> Key: DIRSERVER-1311
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1311
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.4
> Environment: Windows XP
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> ApacheDS 1.5.4
> Reporter: Stefan Zoerner
> Assignee: Stefan Seelmann
> Priority: Minor
> Fix For: 2.0.0-RC1
>
> Attachments: tori.ldif
>
>
> I use an out of the box ApacheDS 1.5.4 with server.xml unchanged, context entry for dc=example,dc=com
created.
> Adding the following entry is successful (LDIF import)
> dn: cn=Amos\,Tori,dc=example,dc=com
> sn: Amos
> objectClass: person
> objectClass: top
> cn: Tori Amos
> If I perform searches, some find it, for instance:
> $ ldapsearch -D "uid=admin,ou=system" -w secret -h localhost -p 10389 -b "dc=example,dc=com"
-s one "(objectclass=person)"
> version: 1
> dn: cn=Amos\,Tori,dc=example,dc=com
> objectClass: person
> objectClass: top
> cn: Tori Amos
> cn: Amos\,Tori
> sn: Amos
> $
> But the following fails (no entry found):
> $ ldapsearch -D "uid=admin,ou=system" -w secret -h localhost -p 10389 -b "dc=example,dc=com"
-s one "(cn=Amos,Tori)"
> $
> According to Open Group's compliance tests, it should return the entry. I have tried
to verify this by reading RFC 2253 and RFC 4514, esacping with a bachslash is allowed (I am
not 100% certain about the filter ...).
> Note that this one here does not return an entry either.
> $ ldapsearch -D "uid=admin,ou=system" -w secret -h localhost -p 10389 -b "dc=example,dc=com"
-s one "(cn=Amos\,Tori)"
> $
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
|