Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.
Filtering the results
In addition to filtering the return values on the server side by looking for attributes, you can set the search up to provide extra filtering. Your filtering options will vary depending on the variant of search() you call.
First on the list of variants is the ability to request only a small list of attributes. If you know that you only need to deal with the SearchResult instances and not a DirContext, then you can use the matching attributes arguments to limit the list of attributes returned, in much the same way that getAttributes() enables you to use a list of required attributes. This might be useful if you want to do that initial search for caller details by simply checking the e−mail address for a match, as in the following example: String reqd_attrs = new String[] { "cn", "uid",
"rfc822mailalias" };
NamingEnumeration results =
initial_ctx.search("ou=Customer,o=ExampleApp",
search_attrs,
reqd_attrs);
If you want to get even more picky about how much searching to do, you can also supply a filter and SearchControls instance. This filter acts like the filter argument to the ldapsearch command−line tool.
SearchControls information is much more interesting. You can use this class to limit the scope of your search to, say, a single level of the directory−service hierarchy, or to place a maximum limit on the search results.
For example, if you use your LDAP database to store all the books you have in stock, and the end user does a subject search for Java books, you might want to limit the returned results to the first 20 books found rather than listing all 2,000−odd titles that you hold, as in the following example: SearchControls ctrls = new SearchControls();
ctrls.setCountLimit(20);
ctrls.setTimeLimit(5000);
ctrls.setSearchScope(SearchControls.SUBTREE_SCOPE);
NamingEnumeration results =
initial_ctx.search("cat=books,ou=Products,o=ExampleApp",
"title=*Java*",
ctrls);
Tip For more details on the format of the filter string, look at RFC 2254.
185
Chapter 9: Accessing Directory Services with JNDI Modifying existing data
Probably the most common action in a directory service is modifying the attributes. For example, users sometimes move and need to update their contact details. To update those details, you need to modify the attributes of the contexts that belong to those users.
Note Modifying data, in this instance, means adding, removing, or changing the attributes of a particular context. Deleting or adding a whole new context requires a different process; we address it in its own section later in the chapter on changing the structure of the directory service.
Setting up the attributes to be modified
The first step in modifying attributes is knowing which ones need to be updated and constructing the appropriate data structures. You modify attributes with the modifyAttributes() method of the DirContext interface; doing this requires an instance of Attributes.
The list of attributes you supply to the context must be the list of attributes to be modified and their new values. Each time you make an update to the directory service the list must be created fresh with the new values. You must remember that this list must be fresh each time — once you have made updates, you need to clear the list of existing values and then repopulate it with new values. You can't provide an attribute with a value equal to the values already in the database. This effectively prevents you from fetching a set of attributes, modifying one or two, and then passing the list back to the modifyAttributes() method. You need to keep two separate lists — one of the original values and one of the values that have been modified since the last time you requested an update.
For example, you could modify a user's details with a method like the following: public void updateAddress(String dn,
String address,
String country,
String phone) {
BasicAttributes mod_attrs = new BasicAttributes();
if(address != null)