En el JNDI, cada nombre se resuelve en relación a un contexto. Para empezar, normalmente creamos un contexto inicial usando uno de los constructores de las clases InitialContext, InitialDirContext, o InitialLdapContext.

La lección Propiedades de Entorno contiene ejemplos de cómo usar estos constructores.

Una vez que tenemos un ejemplar de un Context, podemos buscar otros contextos y realizar operaciones de nombrado en relación a esos contextos. Los nombres suministrados a todos esos contextos son nombres relativos. Es decir, son interpretados en relación al contexto en el que suministraron.

Lo más cercano a un nombre absoluto en JNDI es un string URL. En JNDI, podemos suministrar un string URL a los métodos de las clases InitialContext y InitialDirContext. (La clase InitialLdapContext no declara ningún método que acepte un argumento nombre, aunque hereda todos los métodos de las clases InitialContext y InitialDirContext.)

Cuando suministramos un string URL, que es un string de la forma.

esquema: partes-específicas-del-esquema

a un método de InitialContext o InitialDirContext, como lookup(), el nombre es tratado como un string URL en vez de un nombre relativo al contexto inicial. Aquí tenemos un ejemplo que busca un objeto usando un string URL LDAP.

La clase InitialContext (y sus subclases) desvían la llamada a método para que sea procesado por la correspondiente implementación del contexto URL, en vez de la implementación del contexto inicial subyacente.

Es decir, si hemos seleccionado la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY, no habría sido usado en la llamada a lookup(). En su lugar, el JNDI hubiera buscado y utilizado la implementación del contexto URL para el esquema URL ldap. Observa que en el ejemplo anterior no se especificó la propiedad Context.INITIAL_CONTEXT_FACTORY al constructor de InitialContext.

La habilidad del JNDI de aceptar strings URLs arbitrarias desde la clase InitialContext (y sus subclases) nos permite acceder a cualquier espacio de nombres en el que tengamos una implementación. Así, no estamos restringidos por el espacio de nombres ofrecido por la implementación nombrada por la propiedad Context.INITIAL_CONTEXT_FACTORY.

Por ejemplo, supongamos que nombramos un proveedor de servicios del sistema de ficheros usando la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY.

Usando el mismo tiempo el ejemplar de InitialContext, podemos acceder a un espacio de nombres LDAP especificando un string URL LDAP y podemos acceder a un espacio de nombres CORBA especificando una string URL CORBA.

Cuando la clase InitialContext recibe un string URL como un argumento nombre de uno de sus métodos, busca una implementación de contexto URL. Hace esto usando la propiedad de entorno Context.URL_PKG_PREFIXES.

Esta propiedad contiene una lista separada por dos puntos de prefijos de paquetes. Cada ítem de la lista es el prefijo de un paquete totalmente cualificado de una factoría de contexto URL. El nombre de la factoría se construye usando la siguiente regla.

prefijo-pquete. esquema. esquemaURLContextFactory

El prefijo de paquete "com.sun.jndi.url" siempre se añade al final de la lista.

Normalmente, un proveedor de servicio que suministra una implementación de contexto también suministrará una implementación de contexto URL para que pueda manejar strings URLs pasadas al InitialContext. Sin embargo, no es obligatorio y algunos proveedores de servicios podrían no suministrar implementanciones de contexto URL. Supongamos que la propiedad URL_PKG_PREFIXES contiene.

También supongamos que se suministra el siguiente string URL al método lookup() de la clase InitialContext.

El JNDI buscará las siguientes clases.

Luego intentará ejemplarizar cada clase por turno llamando a ObjectFactory.getObjectInstance(Object, Name, Context, Hashtable) hasta que una de ellas produzca una respuesta no-null. La respuesta, que es un contexto, se usa para llevar a cabo el método originalmente intencionado, usando el string URL como argumento nombre.

Luego, supongamos que el JNDI ejemplariza satisfactoriamente la clase com.wiz.jndi.ldap.ldapURLContextFactory y obtiene un contexto desde ella. Luego el JNDI llama a lookup() sobre el contexto y le suministra "ldap://localhost:389/cn=homedir, cn=Jon Ruiz, ou=People, o=JNDITutorial" como el string del argumento nombre.

Si el JNDI no puede encontrar una factoría de contexto URL que devuelva una respuesta no-null, se pasa el string URL de entrada a la implementación del contexto inicial subyacente (es decir, la implementación especificada en la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY).

Puedes ir a la sección Construir un Proveedor de Servicio para ver descripciones de cómo escribir una implementación de un contexto URL.

Necesitamos entender que no existe relación entre la implementación nombrada por la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY y cualquier otra implementación de contexto URL distinta a todas las que se pueden encontrar mediante el mismo ejemplar de InitialContext.

Por ejemplo, supongamos, que tenemos la siguiente configuración de propiedades de entorno.

Si suministramso el nombre "ldap://localhost:389/o=JNDITutorial" a InitialContext.lookup(), la lista de clases de factorías de contextos URL intentará esto.

Si el proveedor de servicio viene con una factoría de contextos URL, el proveedor suminstrará un fichero de recursos de apliación (jndi.properties) que contiene el prefijo del paquete de la factoría. Puedes ir a la lección Propiedades de Entorno para ver una descripción de los ficheros de recursos de aplicación. Si el proveedor tiene una factoría de contextos URL pero no ha especificado un prefijo de paquete para ella en el fichero de recursos de aplicación, deberíamos especificarlo en nuestro programa o en el fichero de recursos de aplicación para que el JNDI pueda encontrar la factoría.

Para especificar un string URL como parte de un nombre mixto para los métodos de InitialContext, la ponemos como el primer compomente de un nombre mixto. Haciendo esto, en efecto, usamos el string URL para nombrar un contexto en el que continuar la operación sobre el resto de componentes del nombre.

Aquí tenemos un ejemplo que crea un CompositeName que consiste en string URL LDAP como el primer componente y los nombres de ficheros de los componentes restantes.

No podemos especificar un componentes de nombres mixtos como parte de un propio string URL porque haciendo esto podría tener un conflicto con la síntaxis URL.

Algunas URLs, como las del LDAP (RFC 2255), especifican más de un componente de nombre. La síntaxis URL de LDAP permite especificar el ámbito de búsqueda y la consulta de búsqueda, así como los atributos a devolver. Puedes ir a la lección Miscelánea para ver más información y ejemplos de cómo se usan los componentes de consultas en un string URL.