[ http://issues.apache.org/jira/brows...ER-804?page=all ]

Stefan Zoerner closed DIRSERVER-804.
------------------------------------

Assignee: Emmanuel Lecharny

I have retested the current 1.0.1, and it works fine: Both Softerra LDAP Adm
inistrator and the command line ops described in the issue don't cause an er
ror anymore. Hence I close this issue. Thanks, Emmanuel!

> Some searches for user and operational attributes fail, if denormalizeOpAt
trsEnabled is enabled
> --------------------------------------------------------------------------
---------------------
>
>                 Key: DIRSERVER-804
>                 URL: http://issues.apache.org/jira/browse/DIRSERVER-804
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0, 1.0.1
>         Environment: * ApacheDS 1.0.1 (SNAPSHOT)
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> * Windows XP Professional SP2
>            Reporter: Stefan Zoerner
>         Assigned To: Emmanuel Lecharny
>            Priority: Minor
>         Attachments: DIRSERVER-804.log, DIRSERVER-804.patch
>
>
> If  the property denormalizeOpAttrsEnabled is enabled in the server.xml co
nfiguration,
>     <property name="denormalizeOpAttrsEnabled"><value>true</value></proper
ty>
> some searches cause unknown errors.
> Here is an example:
> $ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -b "
ou=system" -s base "(ObjectClass=*)" * +
> ldap_search: Unknown error
> $
> If the attribute sets "+" and "*" are used alone, no error occurs.  And if
 denormalizeOpAttrsEnabled is set to false (which is the default), no error 
occurs as well with the "* +" combination.
> After a change in the logging configuration, I learned that deep in the Op
erationalAttributeService, a runtime exception occurs:
> Caused by: java.lang.IllegalStateException: Cannot add duplicate to unorde
red attribute
> 	at javax.naming.directory.BasicAttribute.set(Unknown Source)
> 	at org.apache.directory.server.core.operational.OperationalAttributeServi
ce. denormalizeEntryOpAttrs(OperationalAttri
buteService.java:382)
> 	at org.apache.directory.server.core.operational.OperationalAttributeServi
ce. filterDenormalized(OperationalAttributeS
ervice.java:441)
> 	at org.apache.directory.server.core.operational.OperationalAttributeServi
ce.access$000(OperationalAttributeService.java:69)
> 	at org.apache.directory.server.core.operational.OperationalAttributeServi
ce$1.accept(OperationalAttributeService.java:78)
> 	at org.apache.directory.server.core.enumeration.SearchResultFilteringEnum
eration. prefetch(SearchResultFilteringEnumeratio
n.java:302)
> 	at org.apache.directory.server.core.enumeration.SearchResultFilteringEnum
eration.<init>(SearchResultFilteringEnumeration.java:109)
> 	at org.apache.directory.server.core.operational.OperationalAttributeServi
ce.search(OperationalAttributeService.java:292)
> 	at org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.
search(InterceptorChain.java:1263)
> 	... 36 more
> You find the complete log attached to this issue.
> Btw: (for those who ask why I submit such an obscure search op): I orginal
ly faced this problem when using Softerra LDAP Administrator to browse the d
irectory. It caused ugly errors in the UI.
> Finally I was able to figure out what it is all about. The original query 
by the Softerra tool was:
> $ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -b "
ou=system" -s base "(ObjectClass=*)" createtimestamp + * modifiersname subsc
hemasubentry modifytimestamp creatorsname hassubordinates
> ldap_search: Unknown error
> $

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://iss
ues.apache.org/ji...nistrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]