JNDI Environment & Service Naming Contexts

Version:

$Revision: 1.4 $ $Date: 2001/03/13 20:59:02 $

Author:

Assaf Arkin

An in-memory namespace is available through the {@link tyrex.naming.MemoryContext} JNDI service provider. The in-memory namespace holds objects directly in memory including factories and services that cannot be held in a persistent namespace. It supports two modes of operation, a tree shared between all instances through a shared namespace, and trees created dynamically with access controlled by their creator. See In-Memory Context for more details.

The in-memory JNDI service provider has the following properties:

• It is held entirely in memory for fast access and manipulations
• It is persisted indirectly through copying to XML files or persistent JNDI namespaces (e.g. LDAP, CosNaming, etc)
• It supports binding of persistent (serializable and referenceable), remote (RMI/IIOP) and active objects (resource factories, services, etc).
• It is a full JNDI service provider supporting sub-context creation and destruction, lookup and name parsing, heirarchial structure, links, etc.
• It provides the basis for the JNDI Environment Naming Context

The caller must had adequate security permission to access the shared in-memory namespace (creating a private namespace requires no permission) and to set/unset the ENC for the current thread, see Access Permissions for more details.

In-Memory Context

{@link tyrex.naming.MemoryContext} is an in-memory JNDI service provider. It binds objects into a namespace held entirely in memory, supporting serializable, remoteable and local objects. The in-memory service provider is particularly useful for holding resource factories (the JNDI ENC) and exposing run-time services and configuration objects.

An instance of {@link MemoryContext} constructed with no environment attribute will use it's own tree of bindings. Such a tree is no accessible except through context created from the original context, and is garbage collected when all such contexts are no longer referenced. If necessary the root context can be duplicated using lookup( "" ).

If the environment attribute {@link Context.PROVIDER_URL} is used, the context will reference a node in a tree shared by all such contexts. That tree is statically held in memory for the life time of the virtual machine.

{@link tyrex.naming.MemoryContextFactory} implements a context factory for {@link MemoryContext}. When set properly {@link javax.naming.InitialContext} will return a {@link MemoryContext} referencing the named path in the memory model. Typically applications will use it to construct an in-memory namespace under the shared root, e.g.:

MemoryContextFactory factory;
Hashtable            env;

// Set up the path
env = new Hashtable();
env.put( Context.PROVIDER_URL, "services" );
// Obtain the context for services
factory = new MemoryContextFactory();
ctx = factory.getInitialContext( env );

// Alternatively, construct MemoryContext directly

env = new Hashtable();
env.put( Context.PROVIDER_URL, "services" );
ctx = new MemoryContext( env );
    

Environment Naming Context

{@link tyrex.naming.java.javaURLContextFactory} implements a URL context factory for the java: URL. It exposes java:/comp as a read-only context as per the J2EE container requirements. To use this context factory the JNDI properties file must include the following property: java.naming.factory.url.pkgs=tyrex.naming.