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.
�Inicializaci�n
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.
�Propietarios
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:
if (inEnv != null) {
myEnv = (Hashtable)inEnv.clone();
} else {
myEnv = new Hashtable();
}
�Herencia
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:
- Cuando una implementaci�n de contexto crea un ejemplar Context, deber�a pasar el entorno del ejemplar Context padre al ejemplar recien creado. Esto puede hacerse clonando el entorno o usando una pol�tica de copia-escribe para que cada entorno de contexto mantenga su independencia.
- Cuando una implementaci�n de contexto invoca a alguno
de los siguientes m�todos deber�a pasarle su entorno de
contexto:
- NamingManager.getObjectInstance(Object, Name, Context, Hashtable)
- DirectoryManager.getObjectInstance(Object, Name, Context, Hashtable, Attributes)
- NamingManager.getStateToBind(Object, Name, Context, Hashtable)
- DirectoryManager.getStateToBind(Object, Name, Context, Hashtable, Attributes)
- ControlFactory.getControlInstance(Control, Context, Hashtable)
La factor�a, o ejemplar de Context derivado de la factor�a resultante de estas llamadas es responsable de clonar el entorno cuando sea necesario.
- Cuando una implementaci�n de contexto que soporta federaci�n alcanzada los l�mites de su sistema de nombres, construye una CannotProceedException que apunta lo lejos que ha llegado y luego llama a NamingManager.getContinuationContext() o a DirectoryManager.getContinuationDirContext(). La implementaci�n de contexto deber�a llamar a CannotProceedException.setEnvironment() con el entorno de contexto. Al hacer esto se pasa el entorno de contexto al contexto de continuaci�n en el nns (sistema de nombres siguiente). El contexto en el nns es responsable de clonar el entorno cuando sea necesario.
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.
�Aplicabilidad
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.
�Ficheros de Recursos de Proveedor
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:
java.naming.factory.object java.naming.factory.state java.naming.factory.control java.naming.factory.url.pkgs
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.
�Propiedades Espec�ficas del Proveedor
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.".