Link Reference

A link reference is a symbolic link that can span multiple naming systems. It is represented by the LinkRef class. Its contents 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), 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 Referenceand Referenceableobjects. When you subsequently perform a Context.lookup()or other context operation involving the link reference, it 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. When you subsequently list the context by using the name here/over/there, that's effectively the same as if you had used the name some/where/over/there.
The only time that a link reference is not dereferenced is when you use Context.lookupLink(). In that case, if the link reference is bound to the terminal component of the composite name, it is returned as is without being dereferenced. In the above example, if you invoke this statement:
Object obj = ctx.lookupLink("here");
the result would be a LinkRef that contains the composite name some/where. If the name you supply to lookupLink() contains a component bound to a link reference as a nonterminal component, the link reference is still dereferenced. In the above example, if you invoke this statement:
Object obj = ctx.lookupLink("here/over/there");
the result would 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 file system service provider currently support 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 support aliases and referrals. The JNDI supports URL references (see the URLs lesson). The JNDI link reference is different 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 the link reference is not LDAP specific and can name objects outside of the LDAP namespace or server. Unlike an alias, a link reference is process 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 a link reference 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 a link reference need not name another file or directory.
A link reference differs from a URL reference in that a link reference is explicitly typed and designed to support links, while a URL reference is intended primarily for supporting 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