Adding Event Notification Support

Prerequisite: You should be familiar with the event model used by the JNDI before reading this section. The event model is covered in the Event Notification lesson.

A service provider typically supports event notification only when the underlying naming/directory service provides such a feature. However, a service provider may support event notification even if the underlying service does not. It simply needs to do more work and perhaps offer the feature by polling the underlying service for changes.

Architectural Overview
Event notification can be implemented in several different ways. Following is one sample architecture. However, the one that works for your service provider will depend on the features of the underlying naming/directory service.
To add event notification support, you need the following three components.

Bookkeeper. Maintains the list of listeners and is responsible for implementing the registration/deregistration methods in the EventContext and EventDirContext interfaces.
Notifier. Notifies the listener(s) of an event. The occurrence of an event is typically triggered by an asynchronous change in the underlying service. The notifier detects the change (for example, via a message from the underlying service or by polling the state of the underlying service) and puts a corresponding event in the event queue.
Event Queue. Maintains a queue of events that have occurred and fires the events to the registered listeners.
To implement event notification, your context implementation must implement either the EventContext or EventDirContext interface. The bookkeeper might be a part of the context implementation or a utility used by the context implementation. When a program registers a listener, the bookkeeper records the listener and the target in which it is interested. It then uses--creates or uses one from a thread pool--a notifier to track the target. Typically, the notifier is a thread that listens for changes to the target. When the notifier detects a change that will trigger an event, it creates an event that contains the appropriate information and puts it in the event queue. The notifier then returns to listening for future changes. The event queue is monitored by an event queue manager thread, whose job is to remove an event from the queue and dispatch it to the appropriate listeners.
Implementation Tips
Here are some tips to keep in mind when developing your context implementation.

Handling listener registration.
Listener registration is associated with a Context instance and not the representation of the context in the underlying service. For example, suppose that you are using the LDAP service. You cannot expect to register a listener with one Context instance and remove it from another Context instance, even if both represent the same LDAP entry. Therefore your implementation should maintain separate listener lists for separate Context instances.
When to deregister.
Some events cause automatic deregistration. If a listener receives an exception or if the Context instance with which it has registered is closed, then the listener is automatically deregistered and will receive no further events. Your notifier implementation should pay attention to the exception events that it generates and tell the bookkeeper to deregister listeners that receive such events (but only after the exception events have been delivered).
Using threads.
Regardless of whether you choose to follow the sample architecture described previously in this section, support for event notification requires the use of threads. Furthermore, these threads manipulate shared data such as Context instances, event queues, and listener lists. Be sure to have a good understanding of the threads model in the Java programming language.

Miscellaneous