Previous | Next | Trail Map | Building a Service Provider | The Essential Components

Miscellaneous

This section describes additional miscellaneous issues that a context implementation must handle.

Resource Management

The Java programming language provides automatic garbage collection. This means that when an object is no longer being referenced, the Java runtime will automatically dispose of it. close()(in the API reference documentation) gives the API user a way to dispose of a Context instance and its associated resources before automatic garbage collection kicks in. This is important for network-based context implementations because network connections are a limited resource for both clients and servers. The flat namespace example does not provide any substantial implementation for close(). An actual implementation, especially one that must manage network connections, would define close() to clean up references and connections.

Environment Properties

The Ground Rules (in the Building a Service Provider trail) lesson describes how a context implementation should treat its environment properties. Even though the flat namespace and hierarchical namespace examples don't use any environment properties, they must provide implementations for the environment-related methods.

As suggested by the The Ground Rules (in the Building a Service Provider trail) lesson, getEnvironment()(in the API reference documentation) should provide a read-only copy or a clone of its environment properties to its caller.

addToEnvironment()(in the API reference documentation) and removeFromEnvironment()(in the API reference documentation) are used by a program to update a context's environment. The flat namespace example simply updates its internal environment hash table. An actual implementation would examine the property name and act appropriately to update the Context instance's behavior accordingly.

Unsupported Operations

A context implementation must provide a valid implementation for lookup()(in the API reference documentation). For all other methods, if a context implementation does not support a particular method, then the method definition should throw an OperationNotSupportedException(in the API reference documentation).

For example, a context implementation for a read-only underlying naming service cannot support any methods that involve updates. Here is an example of such a context implementation's definition of Context.bind()(in the API reference documentation).

public void bind(Name obj, Object obj) throws NamingException {
    throw new OperationNotSupportedException(
        "Read-only service does not support updates");
}


Previous | Next | Trail Map | Building a Service Provider | The Essential Components