I am using SimplePagedResultsControl to page my results and I am able to retrieve the first set of results according to the page size I set in the SearchRequest. But the SearchResult contains no ResponseControl for me to extract the cookie and pass it in the next SearchRequest.
LDAPConnectionOptions connectionOptions = new LDAPConnectionOptions();
connectionOptions.setUseSynchronousMode(true);
try {
LDAPConnection connection = new LDAPConnection(connectionOptions,
"servername", port);
SimpleBindRequest bindRequest = new SimpleBindRequest(
"cn=example,dc=net",
"password");
connection.bind(bindRequest);
SearchRequest searchRequest = new SearchRequest(
searchResultListener,
"ou=example,dc=net",
SearchScope.SUB, DereferencePolicy.NEVER, 0, 0, false,
Filter.createPresenceFilter("objectClass"));
ASN1OctetString cookie = null;
searchRequest.addControl(new SimplePagedResultsControl(5,cookie, true));
System.out.println("Perform a search");
SearchResult result = connection.search(searchRequest);
for (SearchResultEntry entry : result.getSearchEntries()) {
System.out.println(entry.getAttributes());
}
LDAPTestUtils.assertHasControl(result,
SimplePagedResultsControl.PAGED_RESULTS_OID);
System.out.println(result.getResponseControl(SimplePagedResultsControl.PAGED_RESULTS_OID));
...........
}
From the exception that get printed from the below code, I am able to see that the ReferenceURL has the SimplePagedResultsControl and the number of remaining entries.
What am I missing that the ResponseControl is null in the SearchResult?
I am sure the directory server supports SimplePagedResultsControl as I am able to get this work using Java LDAP JNDI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saw your comment on Stack Overflow that indicated that the control information appears to be showing up in the referral URLs element of the response. I've looked through the LDAP SDK to see if there's any way that it could possibly be screwing something up, but I can't find anything. And since this control definitely works as expected in all the cases I've tried to use it, it is likely something specific to the server that you're trying to use.
In this case, it might be useful to verify exactly what traffic is coming back from the server. The ldap-debugger tool provided with the LDAP SDK could help with this. It acts as a simple LDAP proxy that sits between the client and the directory server and decodes all traffic that passes through it. You can run it with the command:
where {ds-address} and {ds-port} are the address and port of the directory server to which requests should be forwarded, {listen-port} is the port on which the ldap-debugger tool should listen for connections, and {output-path} is the path to the file into which the decoded traffic. If you run your program by connecting to the ldap-debugger tool instead of the actual directory server, then it will write out a detailed representation of the request it receives from the client before forwarding it on to the directory server, and then it will write out a detailed representation of the response it receives from the server before forwarding it on to the client. Once your program is done, you can kill the ldap-debugger and look at its output file to see what the server sent back. If you could provide that information, it would be extremely helpful in verifying whether the problem exists in the server or the LDAP SDK.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Neil! I have done what you have mentioned above and attached the output file from ldap-debugger. One thing which I noticed is that the values present in the referral URL are having some control characters. Does the cookie value from the response control look similar to what we see in the referral url?
This pretty much confirms that it's a bug in whatever directory server you're using. I would recommend contacting the vendor or using whatever support channel they have in place to report the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok. Let me check with the support. I am connecting to Oracle Internet Directory and the one thing which I am still confused is how the pagination is working fine when using Java LDAP JNDI.
I have a code similar to what's given in the link below and it works perfectly. The search result contains the needed response controls.
Could you also use the ldap-debugger tool to capture the JNDI communication? That would help understand exactly what is different about the request being sent and might illuminate the reason for the difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
See my latest response in the thread that you referenced. The problem lies in the Oracle OID server, and there's nothing to be resolved in the LDAP SDK.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using SimplePagedResultsControl to page my results and I am able to retrieve the first set of results according to the page size I set in the SearchRequest. But the SearchResult contains no ResponseControl for me to extract the cookie and pass it in the next SearchRequest.
LDAPConnectionOptions connectionOptions = new LDAPConnectionOptions(); connectionOptions.setUseSynchronousMode(true); try { LDAPConnection connection = new LDAPConnection(connectionOptions, "servername", port); SimpleBindRequest bindRequest = new SimpleBindRequest( "cn=example,dc=net", "password"); connection.bind(bindRequest); SearchRequest searchRequest = new SearchRequest( searchResultListener, "ou=example,dc=net", SearchScope.SUB, DereferencePolicy.NEVER, 0, 0, false, Filter.createPresenceFilter("objectClass")); ASN1OctetString cookie = null; searchRequest.addControl(new SimplePagedResultsControl(5,cookie, true)); System.out.println("Perform a search"); SearchResult result = connection.search(searchRequest); for (SearchResultEntry entry : result.getSearchEntries()) { System.out.println(entry.getAttributes()); } LDAPTestUtils.assertHasControl(result, SimplePagedResultsControl.PAGED_RESULTS_OID); System.out.println(result.getResponseControl(SimplePagedResultsControl.PAGED_RESULTS_OID)); ........... }From the exception that get printed from the below code, I am able to see that the ReferenceURL has the SimplePagedResultsControl and the number of remaining entries.
LDAPTestUtils.assertHasControl(result, SimplePagedResultsControl.PAGED_RESULTS_OID);
What am I missing that the ResponseControl is null in the SearchResult?
I am sure the directory server supports SimplePagedResultsControl as I am able to get this work using Java LDAP JNDI.
I saw your comment on Stack Overflow that indicated that the control information appears to be showing up in the referral URLs element of the response. I've looked through the LDAP SDK to see if there's any way that it could possibly be screwing something up, but I can't find anything. And since this control definitely works as expected in all the cases I've tried to use it, it is likely something specific to the server that you're trying to use.
In this case, it might be useful to verify exactly what traffic is coming back from the server. The ldap-debugger tool provided with the LDAP SDK could help with this. It acts as a simple LDAP proxy that sits between the client and the directory server and decodes all traffic that passes through it. You can run it with the command:
tools/ldap-debugger --hostname {ds-address} --port {ds-port} \ --listenPort {listen-port} --outputFile {output-path}where {ds-address} and {ds-port} are the address and port of the directory server to which requests should be forwarded, {listen-port} is the port on which the ldap-debugger tool should listen for connections, and {output-path} is the path to the file into which the decoded traffic. If you run your program by connecting to the ldap-debugger tool instead of the actual directory server, then it will write out a detailed representation of the request it receives from the client before forwarding it on to the directory server, and then it will write out a detailed representation of the response it receives from the server before forwarding it on to the client. Once your program is done, you can kill the ldap-debugger and look at its output file to see what the server sent back. If you could provide that information, it would be extremely helpful in verifying whether the problem exists in the server or the LDAP SDK.
Thanks Neil! I have done what you have mentioned above and attached the output file from ldap-debugger. One thing which I noticed is that the values present in the referral URL are having some control characters. Does the cookie value from the response control look similar to what we see in the referral url?
This pretty much confirms that it's a bug in whatever directory server you're using. I would recommend contacting the vendor or using whatever support channel they have in place to report the problem.
ok. Let me check with the support. I am connecting to Oracle Internet Directory and the one thing which I am still confused is how the pagination is working fine when using Java LDAP JNDI.
I have a code similar to what's given in the link below and it works perfectly. The search result contains the needed response controls.
http://docs.oracle.com/javase/tutorial/jndi/newstuff/paged-results.html
Could you also use the ldap-debugger tool to capture the JNDI communication? That would help understand exactly what is different about the request being sent and might illuminate the reason for the difference.
Hello. Was this issue resolved? We have very similar problem using paged search with Oracle OID https://sourceforge.net/p/ldap-sdk/discussion/1001257/thread/ecb0415f/#3ae7
Thanks,
Sergey
See my latest response in the thread that you referenced. The problem lies in the Oracle OID server, and there's nothing to be resolved in the LDAP SDK.