Issue Details (XML | Word | Printable)

Key: DIRSERVER-804
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Emmanuel Lecharny
Reporter: Stefan Zoerner
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Directory ApacheDS

Some searches for user and operational attributes fail, if denormalizeOpAttrsEnabled is enabled

Created: 22/Dec/06 02:57 PM   Updated: 22/Dec/06 08:55 PM
Return to search
Component/s: None
Affects Version/s: 1.0.1, 1.0
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
Text File DIRSERVER-804.log 2006-12-22 03:01 PM Stefan Zoerner 75 kB
Text File Licensed for inclusion in ASF works DIRSERVER-804.patch 2006-12-22 07:44 PM Stefan Zoerner 1 kB
Environment:
* ApacheDS 1.0.1 (SNAPSHOT)
* Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
* Windows XP Professional SP2

Resolution Date: 22/Dec/06 08:47 PM


 Description  « Hide
If the property denormalizeOpAttrsEnabled is enabled in the server.xml configuration,
    <property name="denormalizeOpAttrsEnabled"><value>true</value></property>
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 OperationalAttributeService, a runtime exception occurs:

Caused by: java.lang.IllegalStateException: Cannot add duplicate to unordered attribute
at javax.naming.directory.BasicAttribute.set(Unknown Source)
at org.apache.directory.server.core.operational.OperationalAttributeService.denormalizeEntryOpAttrs(OperationalAttributeService.java:382)
at org.apache.directory.server.core.operational.OperationalAttributeService.filterDenormalized(OperationalAttributeService.java:441)
at org.apache.directory.server.core.operational.OperationalAttributeService.access$000(OperationalAttributeService.java:69)
at org.apache.directory.server.core.operational.OperationalAttributeService$1.accept(OperationalAttributeService.java:78)
at org.apache.directory.server.core.enumeration.SearchResultFilteringEnumeration.prefetch(SearchResultFilteringEnumeration.java:302)
at org.apache.directory.server.core.enumeration.SearchResultFilteringEnumeration.<init>(SearchResultFilteringEnumeration.java:109)
at org.apache.directory.server.core.operational.OperationalAttributeService.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 orginally faced this problem when using Softerra LDAP Administrator to browse the directory. 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 subschemasubentry modifytimestamp creatorsname hassubordinates
ldap_search: Unknown error
$

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Stefan Zoerner added a comment - 22/Dec/06 03:01 PM
The log4j log file which includes the stack trace for this issue.

Stefan Zoerner added a comment - 22/Dec/06 07:44 PM
Here is a patch for the problem. It works both with Softerra UI and the command line examples in the issue description.

I modified the original solution idea, Emmanuel suggested, a bit.
Therefore feedback is welcome before I apply it. And if I should, both in 1.0 and 1.5?


Stefan Zoerner added a comment - 22/Dec/06 08:55 PM
I have retested the current 1.0.1, and it works fine: Both Softerra LDAP Administrator and the command line ops described in the issue don't cause an error anymore. Hence I close this issue. Thanks, Emmanuel!