NamespaceChangeListener listener = ...;
  src.addNamingListener("x", SUBTREE_SCOPE, listener);

  evt.getEventContext() == src
  evt.getOldBinding().getName().equals("x/y")

Contains methods for registering/deregistering listeners to be notified of
 events fired when objects named in a context changes.

Target
 The name parameter in the addNamingListener() methods is referred
 to as the target. The target, along with the scope, identify
 the object(s) that the listener is interested in.
 It is possible to register interest in a target that does not exist, but
 there might be limitations in the extent to which this can be
 supported by the service provider and underlying protocol/service.

 If a service only supports registration for existing
 targets, an attempt to register for a nonexistent target
 results in a NameNotFoundException being thrown as early as possible,
 preferably at the time addNamingListener() is called, or if that is
 not possible, the listener will receive the exception through the
 NamingExceptionEvent.

 Also, for service providers that only support registration for existing
 targets, when the target that a listener has registered for is
 subsequently removed from the namespace, the listener is notified
 via a NamingExceptionEvent (containing a
NameNotFoundException).

 An application can use the method targetMustExist() to check
 whether a EventContext supports registration
 of nonexistent targets.

Event Source
 The EventContext instance on which you invoke the
 registration methods is the event source of the events that are
 (potentially) generated.
 The source is not necessarily the object named by the target.
 Only when the target is the empty name is the object named by the target
 the source.
 In other words, the target,
 along with the scope parameter, are used to identify
 the object(s) that the listener is interested in, but the event source
 is the EventContext instance with which the listener
 has registered.

 For example, suppose a listener makes the following registration:


      NamespaceChangeListener listener = ...;
      src.addNamingListener("x", SUBTREE_SCOPE, listener);
 When an object named "x/y" is subsequently deleted, the corresponding
 NamingEvent (evt)  must contain:


      evt.getEventContext() == src
      evt.getOldBinding().getName().equals("x/y")

 Furthermore, listener registration/deregistration is with
 the EventContext
 instance, and not with the corresponding object in the namespace.
 If the program intends at some point to remove a listener, then it needs to
 keep a reference to the EventContext instance on
 which it invoked addNamingListener() (just as
 it needs to keep a reference to the listener in order to remove it
 later). It cannot expect to do a lookup() and get another instance of
 a EventContext on which to perform the deregistration.
Lifetime of Registration
 A registered listener becomes deregistered when:

It is removed using removeNamingListener().
An exception is thrown while collecting information about the events.
  That is, when the listener receives a NamingExceptionEvent.
Context.close() is invoked on the EventContext
 instance with which it has registered.

 Until that point, a EventContext instance that has outstanding
 listeners will continue to exist and be maintained by the service provider.

Listener Implementations
 The registration/deregistration methods accept an instance of
 NamingListener. There are subinterfaces of NamingListener
 for different of event types of NamingEvent.
 For example, the ObjectChangeListener
 interface is for the NamingEvent.OBJECT_CHANGED event type.
 To register interest in multiple event types, the listener implementation
 should implement multiple NamingListener subinterfaces and use a
 single invocation of addNamingListener().
 In addition to reducing the number of method calls and possibly the code size
 of the listeners, this allows some service providers to optimize the
 registration.

Threading Issues

 Like Context instances in general, instances of
 EventContext are not guaranteed to be thread-safe.
 Care must be taken when multiple threads are accessing the same
 EventContext concurrently.
 See the
 package description
 for more information on threading issues.

Contains methods for registering listeners to be notified
 of events fired when objects named in a directory context changes.

 The methods in this interface support identification of objects by
 RFC 2254
 search filters.

Using the search filter, it is possible to register interest in objects
 that do not exist at the time of registration but later come into existence and
 satisfy the filter.  However, there might be limitations in the extent
 to which this can be supported by the service provider and underlying
 protocol/service.  If the caller submits a filter that cannot be
 supported in this way, addNamingListener() throws an
 InvalidSearchFilterException.

 See EventContext for a description of event source
 and target, and information about listener registration/deregistration
 that are also applicable to methods in this interface.
 See the
 package description
 for information on threading issues.

 A SearchControls or array object
 passed as a parameter to any method is owned by the caller.
 The service provider will not modify the object or keep a reference to it.

Specifies the methods that a listener interested in namespace changes
 must implement.
 Specifically, the listener is interested in NamingEvents
 with event types of OBJECT_ADDED, OBJECT_RENAMED, or
 OBJECT_REMOVED.

 Such a listener must:

Implement this interface and its methods.
Implement NamingListener.namingExceptionThrown() so that
 it will be notified of exceptions thrown while attempting to
 collect information about the events.
Register with the source using the source's addNamingListener()
    method.

 A listener that wants to be notified of OBJECT_CHANGED event types
 should also implement the ObjectChangeListener
 interface.

NamespaceChangeListener listener = ...;
src.addNamingListener("x", SUBTREE_SCOPE, listener);

evt.getEventContext() == src
evt.getOldBinding().getName().equals("x/y")

This class represents an event fired by a naming/directory service.

The NamingEvent's state consists of

The event source: the EventContext which fired this event.
The event type.
The new binding: information about the object after the change.
The old binding: information about the object before the change.
Change information: information about the change
that triggered this event; usually service provider-specific or server-specific
information.


Note that the event source is always the same EventContext
instance  that the listener has registered with.
Furthermore, the names of the bindings in
the NamingEvent are always relative to that instance.
For example, suppose a listener makes the following registration:


    NamespaceChangeListener listener = ...;
    src.addNamingListener("x", SUBTREE_SCOPE, listener);
When an object named "x/y" is subsequently deleted, the corresponding
NamingEvent (evt) must contain:


    evt.getEventContext() == src
    evt.getOldBinding().getName().equals("x/y")

Care must be taken when multiple threads are accessing the same
EventContext concurrently.
See the
package description
for more information on threading issues.

This class represents an event fired when the procedures/processes
used to collect information for notifying listeners of
NamingEvents threw a NamingException.
This can happen, for example, if the server which the listener is using
aborts subsequent to the addNamingListener() call.

This interface is the root of listener interfaces that
handle NamingEvents.
It does not make sense for a listener to implement just this interface.
A listener typically implements a subinterface of NamingListener,
such as ObjectChangeListener or NamespaceChangeListener.

This interface contains a single method, namingExceptionThrown(),
that must be implemented so that the listener can be notified of
exceptions that are thrown (by the service provider) while gathering
information about the events that they're interested in.
When this method is invoked, the listener has been automatically deregistered
from the EventContext with which it has registered.

For example, suppose a listener implements ObjectChangeListener and
registers with a EventContext.
Then, if the connection to the server is subsequently broken,
the listener will receive a NamingExceptionEvent and may
take some corrective action, such as notifying the user of the application.

Specifies the method that a listener of a NamingEvent
 with event type of OBJECT_CHANGED must implement.

 An OBJECT_CHANGED event type is fired when (the contents of)
 an object has changed. This might mean that its attributes have been modified,
 added, or removed, and/or that the object itself has been replaced.
 How the object has changed can be determined by examining the
 NamingEvent's old and new bindings.

 A listener interested in OBJECT_CHANGED event types must:


Implement this interface and its method (objectChanged())
Implement NamingListener.namingExceptionThrown() so that
 it will be notified of exceptions thrown while attempting to
 collect information about the events.
Register with the source using the source's addNamingListener()
    method.

 A listener that wants to be notified of namespace change events
 should also implement the NamespaceChangeListener
 interface.