Before you can perform operations in the naming and directory services, you need to get the initialization context — the starting point of the namespace. Because all methods of naming and directory services are executed relative to some context.

To get the initialization context, you must perform the following steps:

1. Select the access provider you want to access.

2. Specify the initialization context.

3. Call the InitialContext constructor.

Clients of different directories may need to provide different information to connect to the directory. For example, you need to specify the machine on which the server is running and identify the users in the directory. This information is passed to the service provider through environment properties. JNDI specifies the general environment parameters used by the service provider. Your service provider documentation specifies the parameters that need to be provided.

The LDAP provider requires the application to provide the location of the LDAP server, as well as authentication information. To provide this information, the following code is required:

Sun’s LDAP service provider is used in this tutorial. In this example, we assume that the server is set up on the local computer, using port 389, and the root identification name is O =JNDITutorial. Authentication is not required to modify the directory. This information is needed to set up the environment.

If you use a directory with a different setup, you need to set the appropriate environment properties. You need to replace “localhost” with the machine name. You can run the examples on any public directory server or on your own server on another machine. You need to replace “localhost” with the name of that machine and o=JNDITutorial with the appropriate naming context.

Many methods in JNDI packages throw exceptions indicating that the operation request cannot be executed. In general, you’ll see methods that can throw namingExceptions wrapped in try/catch.

Operations such as context.list () and dirContext.search () return NamingEnumeration. In these cases, if an error occurs and no result is returned, NamingException or one of its subclasses is thrown on method request. If an error occurs and partial results are returned, return NamingEnumeration so you can get those results. When all the results are out, and then request NamingEnumeration. HasMore () can lead to throw NamingException (or its subclasses) abnormalities, says there is an error. In this case, enumerations become illegal and no methods can be requested.

For example, if you execute search() and specify how many results to return at most, search() returns at most N results. If the results more than n, then when the first n + 1 times request NamingEnumeration. HasMore (), throw SizeLimitExceededException. See the sample code for limit in this section.

To query objects from the naming service, use the context.lookup () method and pass in the name of the object you want. Suppose the naming service has an object whose name is CN =Rosanna Lee,ou=People. To get this object, you simply write:

The type of object returned by lookup() depends on the naming service and the data associated with the object. A naming service can contain many different types of objects, and objects queried in different parts of the system may yield different types. For example, “cn = Rosanna Lee, ou = People” is bound to the context object (javax.mail. Naming. Ldap. LdapContext). You can cast the result of the lookup() method into the desired class.

For example, the following code queries the “cn=Rosanna Lee,ou=People” object and casts the LdapContext.

The complete example is in the lookup.java file.

Querying names in Java SE 6 introduces two new static methods:

l         InitialContext.doLookup(Name name)

l         InitialContext.doLookup(String name)

These methods provide shortcuts to find objects without instantiating InitialContext.

Context.list() returns an enumeration of NameClassPair. Each NameClassPair contains the object name and the object type name. The following code lists the contents of the “ou=People” directory (for example, files and directories found in the “ou=People” directory).

The return value is as follows:

NamingEnumeration can be terminated in three ways: generic, explicit, and non-explicit.

L when NamingEnumeration. HasMore () returns false, enumerations end terminated at the same time.

You can request the NamingEnumeration. Close () method to explicitly terminate an enumeration before the enumeration is terminated. Doing so prompts the underlying implementation to release any resources associated with enumerations.

L If the hasMore() or next() methods throw any exceptions, the enumeration terminates immediately.

No matter how the enumeration is terminated, once terminated, the enumeration can no longer be used. Calling any method in a terminated enumeration results in inconclusive results.

The Context interface contains methods to add, replace, and delete bindings in the Context.

Rebind () is used to add or replace bindings. Its argument list is the same as bind(), but if the name is already bound, it is first unbound and then rebound to the new object.

When you run this example, you will replace the bindings already created in the bind() example.

You use context.rename () to rename objects in Context.

This example binds an object bound to “cn=Scott Seligman” to “cn=Scott S”. After the validation object is renamed, the program renames it back to its original name (” cn=Scott Seligman “) as follows:

For more examples of renaming in LDAP, see LDAP advanced Notes.

To create a naming context, you provide createSubcontext() with the name of the context to create. Attributes to create a context, the DirContext createSubcontext () you want to create the context and need the name of the property.

This example creates a context named “ou=NewO” and has attributes “objectClass”, “top”, and “organizationalUnit”, where “objectClass” has two values.

This example creates a new context called “NewOu”, which is a subcontext of CTX.

An attribute consists of an attribute identifier and a set of attribute values. An attribute identifier, called an attribute name, is a string representing the attribute. An attribute value is the content of the attribute, and its type is not necessarily a string. When you want to specify get, search, or modify a specified property, you use the property name. The name is also returned in an operation that returns a property (for example, when you perform a read or search operation on a directory).

When using attribute names, you need to know the characteristics of a particular directory server, so you won’t be surprised by the results. These are described in the next subsection.

Some directory implementations support directory subtypes, meaning that the server allows property types to be defined using other property types. For example, the “name” attribute might be a supertype for all name-related attributes: “commonName” is a subclass of Name. For directory implementations that support this tesnagar, accessing the “name” property may return the “commonName” property.

When accessing a directory that supports attributes of subtypes, be aware that the server may return a type that does not match your request. To reduce this probability, use the most derived class.

The LDAP V3 extension (RFC 2596) allows you to specify the language encoding along with the attribute name. Like subclass properties, a property name can represent multiple different properties. For example, the “description” attribute has two different language variants:

A request for the “Description” property returns all three properties. When accessing a directory that supports this feature, you must be aware that the server may return a different name than it requested.

To read the properties of the selected subset, you need to provide an array of the property identifiers you want to get.

This example requests the “sn”, “Telephonenumber”, “golfhandicap” and “mail” properties of the object “CN =Ted Geisel, ou=People”, so these three properties are returned in the reply.

Here is the output:

One way to modify an object’s properties is to provide a list of modificationItems. Each ModificationItem contains numeric constants that indicate the type of modification and describe the properties to be modified. Here are the types of modifications.

l         ADD_ATTRIBUTE

l         REPLACE_ATTRIBUTE

l         REMOVE_ATTRIBUTE

Modifications are made to the types provided in the list. Either all changes are made, or none at all.

The named example discusses how to use overloaded versions of the bind() and unbind(), DirContext methods. You use the methods of DirContext to associate the attributes of the object, adding them to the namespace at binding or subcontext time. For example, you might create a Person object and then bind it to a namespace when you associate properties with the Person object.

Dircontext.rebind () adds or modifies bindings and attributes. It takes the same arguments as bind(). However, if the name already exists with rebind(), new objects and properties will be Unbind first and then bound.

When you run this example, it replaces the binding relationship created in the bind() example.

The simplest queries require you to specify the set of attributes that the entry must contain and the target context for the query.

The following code creates a collection of attributes matchAttrs with two attributes “sn” and “mail”. Table name search entries must have the last name (SN) attribute, which has a value of “Geisel”, and the “mail” attribute, which can be any value. Dircontext.search () is then called to search for entries matching matchAttrs in the context “ou=People”.

The printAttrs() method is similar to the getAttributes() method to print a collection of attributes.

The result is as follows:

In addition to searching with a specified set of attributes, you can search in the form of a search filter. A search filter is a logical expression for searching. The syntax for acceptable filters for dirContext.search () is defined in RFC 2254.

The following search filter specifies that entries that satisfy the query criteria must have an “sn” attribute with a value of “Geisel” and an arbitrary “mail” attribute:

The following code creates the filter and the default SearchControls that you use to execute the query. The results of this query are the same as in the base query.

The search results are as follows:

The previous example returns all attributes in the entry that satisfy the specified filter. You can select the return property by setting the search control parameters. You create want to include in the result set the properties in the identifier, and then he passed to the SearchControls. SetReturningAttributes (). As follows:

This example is consistent with the results in the basic search section that returns selected properties. The result is as follows. (This entry does not have a “golfhandicap” attribute, so it is not returned).

A search of the entire subtree searches not only for the named object but also for its descendants. To make a search in this way, to the SearchControls. According to the following way setSearchScope () passed in the SearchControls. SUBTREE_SCOPE parameters:

This example searches the subtree of the CTX context to get the entries that satisfy the search filter. It finds the “CN = Ted Geisel, ou=People” entry in the subtree that satisfies the filter.

Sometimes, queries may return too many results and you want to limit the size of the result set. At this point you can use a limited number of search controls. By default, there is no limit to the number of searches — it will return all the results it finds. To set up the number of search is limited, passing the figures to the SearchControls. SetCountLimit ().

The following example sets the limit to 1.

If the program trying to get more results, then throws SizeLimitExceededException. If the program sets a number limit, then either treat this exception differently from the NamingExceptions exception or do not request more than the number of results according to the number limit.

Meeting the number of searches is one way to control the resources consumed by the program (such as memory and network bandwidth). Other ways to control resources are to use as small a search filter as possible, start the search in the appropriate context, and use the appropriate scope.

The main problems you may encounter when running a successfully compiled program using JNDI classes are as follows:

L has no initialization context

L The connection was rejected

L Connection failure

L Program hangs

L Name not found

L Cannot connect to any host

L Access system attributes cannot be configured

1. Get NoInitialContextException

Cause: You did not specify the initialization context to use. In particular, the context.initial_context_factory environment variable is not set to the factory class name of the initialization Context. The latter, could not find the service provider available for the context.initial_Context_factory configuration.

Solution: Set the environment variable context.initial_context_factory to the initialization Context class name you use. For details, see the configuration section.

If the properties are set, make sure the class name is correct and that the class is visible in your program (either in your classpath or in the JRE /lib/ext directory). The Java platform includes service providers with LDAP, COS naming, DNS and RMI registration. All other service providers must be installed and added to the execution environment.

2. “CommunicationException” is displayed, indicating “Connection rejected”.

Cause: The server and port represented by the Context.PROVIDER_URL environment parameter do not provide access. Someone may have disabled or shut down the service. Or you entered the wrong server name or port number.

Solution: Check that services are actually running on the ports and restart the server if necessary. This check depends on the LDAP server you are using. Typically, servers can be managed using an administrative console or tools. You can use the tool to confirm the status of the server.

3. The LDAP server responds to other tools (such as the administrative console) but does not respond to requests from your program.

Cause: The server did not reply the LDAP V3 connection to the full backlight bulb. Some servers (especially public servers) do not respond correctly to LDAP V3, using ignore instead of reject. Also, some LDAP V3 servers have error handling mechanisms, and Sun’s LDAP service provider automatically sends and usually returns server-specific error codes.

Solution: Set the environment parameter java.naming.ldap.version to 2. By default, the LDAP service provider tries to connect to the LDAP server using LDAP V3 and then using LDAP V2. If the server silently ignores v3’s request, the provider assumes that the request is valid. With such a server, you must explicitly set the protocol version to ensure that the server behaves correctly.

If the server is v3, try setting these environment parameters before creating the initialization context:

This turns off the control of automatic sending by the LDAP provider (see the JNDI tutorial for more information).

4. The program hangs.

Reason: The server (especially a public one) does not respond (not a failed reply) when you try to perform a verification that produces too many results or requires the server to query too many entries to produce results. The server tries to reduce resource consumption by calculating costs based on pre-requests.

Alternatively, you try to use secure Socket Layer (SSL) but the server/port does not support it, or vice versa (you try to talk to the SSL port using a normal socket).

Eventually, the server either responds very slowly due to load or does not respond at all to some requests.

Solution: If the application is suspended because the server is trying to reduce resource consumption, retry requests will get a single reply or very few replies. This will help you determine if the server is still active. This way, you can widen the original query and resend it.

If your program hangs because of SSL problems, you need to find the SSL port and set the context.security_protocol environment parameter correctly. If the port is an SSL port, this parameter should be set to SSL. This parameter should not be set if it is not an SSL port.

If the program is not for the reason hangs, using com. Sun. Jndi. Ldap. Read. Read timeout timeout. The value of this parameter is a string representing the number of milliseconds that the LDAP request read timed out. If the LDAP provider does not get a response within the period, the read attempt is aborted. The number should be greater than 0. Equal to or less than 0 indicates that no read timeout is specified and is equal to waiting indefinitely for a reply.

If this parameter is not specified, by default it waits until a reply is received.

Such as:

Indicates that if the LDAP server does not respond within 5 seconds, the read request will be abandoned.

5. You get NameNotFoundException exception.

Reason: The root identification name is provided when you initialize the initial context for LDAP. For example, if you set context.provider_URL to “ldap:// LDapServer :389/o=JNDITutorial” for the initial Context and then provide the name “CN =Joe,c=us”, Then the full name you pass to the LDAP service is “CN =Joe, C =us, O =JNDITutorial”. If this is indeed the name you want, you should verify that the server contains the entry.

Also, the Sun Java directory server returns an error if you provide an incorrect identification name during authentication. For example, if you set the context.security_principal environment parameter to “cn=Admin, o=Tutorial” and “cn=Admin, o=Tutorial” is not an entry for the LDAP server, The LDAP provider will throw a NameNotFoundException. The Sun Java directory server is actually returning some authentication exceptions, not “Name not found.”

Solution: Make sure the name you provide exists on the server. You can verify this by enumerating all the entries in the parent context or by using other tools such as the server’s administrator console.

The following are the problems you may encounter when deploying applets.

6. Your applet gets an AppletSecurityException when it tries to connect to the directory server. The server is running on a different machine than the one on which the applet was downloaded.

Reason: The applet is not signed, so it can only connect to the machine from which it was loaded. Alternatively, if appet has been signed, the browser does not grant the applet permission to connect to the directory server.

Solution: If you want to allow an applet to connect to a directory server on any machine, you need to sign the entire applet along with the JNDI JAR used by the applet. For signing jars, see Signing and Verifying JAR files.

7. An AppletSecurityException occurs when your applet attempts to set environment properties using system properties.

Cause: The browser restricts access to system parameters and throws a SecurityException when you try to read.

Solution: If you need input for an applet, try using applet Params instead.

8. Throw an AppletSecurityException when the applet runs in Firefox and tries to authenticate LDAP with CRAM-MD5.

Reason: Firefox prevents access to the java.security package. The LDAP provider USES Java. Security. MessageDigest the information provided in this paper, the function to achieve CRAM – MD5.