Contents

 

 

Adding Directory Support

Whether a context implementation supports directory operations depends to a large extent on the underlying service. If the underlying service is an LDAP directory service, for example, then a mismatch will result if the corresponding context implementation does not support directory operations. By contrast, if the underlying service is the RMI registry, supporting directory operations would make no sense because entries in the RMI registry do not have attributes.

To support directory operations, a context implementation must support methods defined in the DirContext interface in addition to those in the Context interface. This can be done either by defining a class that implements DirContext or by defining a subclass that implements DirContext and extends from a class that implements Context. In the example in this lesson, the latter is used, but there is really no difference between the two.

As with Context methods, a directory context implementation does not have to support all methods in the DirContext interface. For those that it does not support, it should throw an OperationNotSupportedException.

The directory operations can be categorized into five groups:

• Attribute retrieval
• Attribute updates
• Hybrid naming/directory operations
• Searches
• Schema

Within this framework, however, is a lot of leeway in the features that the context implementation supports. None of the features discussed in this section involve adding any new components. Rather, they involve embellishing a context implementation, typically by making existing methods support the feature or by adding new methods.

This lesson also shows how to make a directory context implementation extensible in terms of the types of objects that it accepts for binding and those that it returns to the user program.

 

 

The Attribute Model

In some directory services, attributes are associated with the name of an object, whereas in other directory services, attributes are associated with the object itself. The JNDI does not specify a particular attribute model; both models are equally acceptable. The attribute model of the underlying service might affect the implementation of the context implementation.

Contents