JNDI organizes names and objects in a tree structure similar to a file system. Without understanding the fundamental naming concepts (atomic names, compound names, bindings, contexts), developers cannot effectively navigate or manipulate the JNDI directory tree.
JNDI uses a hierarchical naming model with five key concepts: atomic names (indivisible), compound names (combinations), bindings (name→object associations), contexts (sets of bindings), and subcontexts (contexts within contexts). This mirrors the file system model.
- Atomic Name: A simple, indivisible name (e.g.,
etc,fstab,usr) - Compound Name: Multiple atomic names combined with syntax (
/etc/fstab,/usr/bin) - Binding: Association of a name with an object (
autoexec.bat→ file data) - Context: A set of bindings with distinct atomic names (
/etccontainsmtab,exports) - Subcontext: A context within a context (
/usr/peopleis a subcontext of/usr)
A compound name like /usr/people/ed/.cshrc represents multiple bindings resolved sequentially through the tree.
- Tree structure: Hierarchical, like a file system
- Atomic names: Cannot be subdivided further
- Compound names: Path-like combinations of atomic names
- Bindings: Name-to-object mappings, core of JNDI operations
- Contexts: Containers for bindings, can be nested (subcontexts)
- JNDI compound names: Can use different syntaxes (slash, dot, etc.)
- Built from: JNDI — JNDI implements these naming concepts
- Builds into: JNDI Context — contexts are central to JNDI operations
- Related: JNDI Binding — bindings are the associations within contexts
- Related: Atomic Name, Compound Name
- Related: Subcontext — subcontexts enable hierarchical organization
- Compound name syntax: Different providers may use different separators
- Reserved characters: Some characters may need escaping in names
- Context destruction: Destroying a context may not destroy its subcontexts
- Lazy loading: Large contexts may load bindings lazily
- Compound name parsing: Be careful with provider-specific parsing rules