Link References

A link reference is a symbolic link that can span multiple naming systems. It is represented by the LinkRef class. Its content is a URL string or a composite name. If the first component of the composite name is the string "." (a string consisting of a period character (".")), then the composite name is to be resolved relative to the context in which the link reference is bound. Otherwise, the URL or composite name is to be resolved relative to the initial context.
Relationship to Context Operations
You bind a link reference, like any other object, in a context by using Context.bind() and its related methods. The underlying service provider must support binding Reference and Referenceable objects. When you subsequently perform a Context.lookup() or other context operation involving the link reference, the link reference is automatically dereferenced.
For example, suppose there is the following composite name in the initial context:
some/where/over/there
You create a link reference to "some/where" and bind it to the name "here" in the initial context. Subsequently listing the context by using the name "here/over/there" is effectively the same as using the name "some/where/over/there".
A link reference is not dereferenced only when you use Context.lookupLink(). In this case, a link reference bound to the terminal component of the composite name is returned as is without being dereferenced. In the previous example, if you invoke this statement:
Object obj = ctx.lookupLink("here");
then the result will be a LinkRef that contains the composite name "some/where". If the name that you supply to lookupLink() contains a component bound to a link reference as a nonterminal component, then the link reference will still be dereferenced. In the previous example, if you invoke this statement:
Object obj = ctx.lookupLink("here/over/there");
then the result will be the object bound to "some/where/over/there".

Note: Support for link references is implemented by the underlying service provider. Neither Sun's LDAP service provider nor its file system service provider currently supports link references.

Relationship to Aliases, Referrals, URL References, and Other Symbolic Links
Symbolic links are common in naming and directory systems. For example, the UNIX file system supports symbolic links for files and directories, the LDAP supports aliases and referrals, and the JNDI supports URL references (see the URLs lesson). The JNDI link reference differs from all of these.
An LDAP alias is an LDAP entry that contains the distinguished name of another LDAP entry on the same LDAP server. LDAP servers are responsible for dereferencing aliases. A link reference differs from an alias in that it is not LDAP-specific and can name objects outside of the LDAP namespace or server. Unlike an alias, a link reference is processed on the client side (by the service provider).
An LDAP referral is an LDAP entry that contains the URL of another LDAP entry, possibly on another LDAP server. The URL need not be an LDAP URL, but the entry it names must be an LDAP entry. LDAP clients are responsible for dereferencing referrals. A link reference differs from a referral in that it is not LDAP-specific. It need not name another LDAP entry. A link reference can be relative; that is, it can name another object relative to the context in which the link reference is bound. A referral always contains an absolute URL.
A UNIX symbolic link contains a relative or absolute name of a file or directory. It differs from a link reference in that it can name only another file or directory.
A link reference differs from a URL reference in that it is explicitly typed and designed to support links, whereas a URL reference is intended primarily to support federation. URL references are processed by URL context factories/implementations. Link references are supported by service providers, which are responsible for dereferencing them and performing link loop or link limit detections.

Miscellaneous