Las propiedades de entorno y cómo son usadas por las aplicaciones se describierón con más detalle en la lección Propiedades de Entorno. Esta sección describe cómo un proveedor de servicio debería manejar las propiedades de entorno.

Cuando un programa usa los constructores de la clase InitialContext o sus subclases, suministra un parámetro de entorno opcional. La librería de clases JNDI mezcla los contenidos de este parámetro con otras fuentes de propiedades de entorno (puedes ver la lección Propiedades de Entorno) y da el resultado al proveedor de servicios. Más precisamente, el JNDI da el resultado al InitialContextFactory.getInitialContext(), que a su vez crea la implementación de contexto y suministra las propiedades de entorno resultantes como parámetros. La implementación de contexto no tiene que preocuparse de dónde vienen las propiedades o con consultar varias fuentes. Las librerías de clases JNDI consiguen y mezclan las propiedades antes de dárselas a la implementación de contexto subyacente.

Normalmente, la implementación de contexto necesita recordar los contenidos del entorno más hayá de la inicialización de la implementación de contexto. Como mínimo, la implementación de contexto necesita el entorno para procesar Context.getEnvironment(). Al igual que todos los otros parámetros recibidos mediante una implementación de contexto, las propiedades de entorno son propiedad del llamador y no de la implementación de contexto. Por lo tanto la implementación de contexto necesita hacer una copia del entorno.

Un patrón común en los constructores de implementaciones de contexto es una que clona el entorno, de esta forma:

Se dice que un ejemplar de Context es descendiente de otro ejemplar de Context si éste último fue invocado en la creacción del primero. Por ejemplo, si obtenemos un ejemplar de Context B realizando una Context.lookup() sobre el ejemplar Context A, entonces el ejemplar B desciende del ejemplar A. De forma similar, si listamos un contexto y obtenemos un conjunto de otros ejemplares Context, estos otros ejemplares descienden del contexto listado.

Un ejemplar de Context hereda su entorno del contexto del que desciende, incluso más allá de los límites del sistema de nombres. Aquí tenemos los tres lugares donde una implementación de contexto debería pasar su entorno:

Observa que la herencia ocurre en el momento en que se crea el ejemplar Context derivado. La herencia no significa compartir. Cada ejemplar Context debe mantener su propio entorno esta es la forma de que cualquier cambio en su entorno no afecte al entorno de otros ejemplares de Context.

Posiblemente no todas las propiedades de entorno pasadas a un contexto se aplicarán a esa implementación de contexto. La implementación es responsable de seleccionar y usar aquellas propiedades que se le aplican y de mantener e ignorar las que no. El contexto es responsable de pasar todas las propiedades, incluyendo aquellas que no usan, a los ejemplares Context que descienden de él. Esto permite a la aplicación configurar en un lugar las propiedades de entorno para todas las implemetnaciones de contexto con las que va a interactúar en lugar de sólo aquellas para el contexto inicial.

Los métodos SPI de JNDI listados anteriormente (getObjectInstance(), getStateToBind(), y getControlInstance()) no sólo usan las propiedades encontradas en el parámetro entorno, sino que también usa el fichero de recursos de proveedor. El JNDI localiza este fichero usando el parámetro Context. El nombre del fichero es [prefijo/]jndiprovider.properties donde prefijo es el nombre del parámetro Context y cada caracter punto (".") es convertido a un caracter de barra invertida ("/"). Por ejemplo, supongamos que el parámetro Context es un ejemplar de la clase com.sun.jndi.ldap.LdapCtx. Su fichero de recursos de proveedor se llamará com/sun/jndi/ldap/jndiprovider.properties.

Los métodos SPI de JNDI consultan el fichero de recursos de proveedor cuando determinan los valores de las siguientes propiedades:

Estos valores son añadidos a los valores encontrados en el parámetro entorno.

Otras propiedades distintas de estas podrían configurarse en el fichero de recursos de proveedor a la discrección del proveedor de servicio. Estas propiedades adicionales son ignoradas por el JNDI pero podría usarlas el proveedor de servicio. Si nuestro proveedor usa propiedades adicionales desde el fichero de recursos de proveedor deberíamos documentarlas claramente.

La lección propiedades de entorno explica las diferentes categorías de propiedades de entorno. Las propiedades de entorno específicas del proveedor sólo son usadas por un proveedor de servicio específico. Antes de definir una propiedad de entorno específica de servidor, deberíamos asegurarnos que debe ser específica del proveedor y no puede ser específica del servicio o de una caracterísitca. Puedes ver en la lección Propiedades de Entorno más información sobre cómo categorizar las propiedades de entorno.

Cuando definimos una propiedad específica del proveedor, deberíamos precederla con el nombre del paquete de nuestro proveedor de servicio. Por ejemplo, si nuestra implementación de contexto tiene el nombre de clase com.sun.jndi.ldap.LdapCtx, entonces sus propiedades específicas deberían estár precedidas por "com.sun.jndi.ldap.".