
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Windows 2000, JDK 1.4.2_03
|
|
| Resolution Date: |
14/Sep/08 08:43 AM
|
|
I executed a search on a context and the search did not return.
2006-11-23 15:20:18,243 DEBUG [MYLDAPClientClass]function - searching : filter [(&(cn=somerandomstring)(objectClass=RakInstanceDescriptor)]
I noticed from my debug that my search filter was not terminated correctly. It would make development easier, especially for those not knowing immediately that they had provided a duff filter, if the search method threw an exception to say that the filter was invalid.
|
|
Description
|
I executed a search on a context and the search did not return.
2006-11-23 15:20:18,243 DEBUG [MYLDAPClientClass]function - searching : filter [(&(cn=somerandomstring)(objectClass=RakInstanceDescriptor)]
I noticed from my debug that my search filter was not terminated correctly. It would make development easier, especially for those not knowing immediately that they had provided a duff filter, if the search method threw an exception to say that the filter was invalid.
|
Show » |
|
The reason is that the server don't receive the filter the way you write it. The LdapProtocol for a Search Request is a binary protocol, not a textual one, and the search filter is written this way for your request :
(&(cn=somerandomstring)(objectClass=RakInstanceDescriptor))
is translated to :
0xA0
0xA3 0x16
0x04 0x02 'c'n'
0x04 0x10 'somerandomstring'
0xA3 0x24
0x04 0x0B 'objectClass'
0x04 0x15 'RakInstanceDescriptor'
This is the client side parser which should be fixed...
Ok, now, if you use the shared-ldap API to parse the filter, then we have a problem, but this is another JIRA :)