Cuando creamos un InitialContext, InitialDirContext, o un InitialLdapContext usando el proveedor de servicio LDAP, se configura inmediatamente una conexi�n con el servidor LDAP objetivo. Todos los contextos y NamingEnumerations que se deriven de este contexto inicial comparten la misma conexi�n que el contexto inicial
Por ejemplo, si llamamos a Context.lookup() o a Context.listBindings() desde el contexto inicial y obtenemos de vuelta otros contextos, entonces todos esos contextos compartir�n la misma conexi�n. Si creamos un nuevo contexto inicial, tendr� su propia conexi�n.
Cuando cambiamos las propiedades de entorno que est�n relacionadas con una conexi�n, como el nombre o las credenciales del usuario, el contexto sobre el que hemos hecho esos cambios obtendr� su propia conexi�n (si la conexi�n es compartida). Los contextos que desciendan de este contexto en el futuro compartir�n esta nueva conexi�n, pero aquellos que la compart�an anteriormente no se ver�n afectados (es decir, continuaran usando la vieja conexi�n).
De forma similar, si usamos LdapContext.reconnect(), entonces el ejemplar Context sobre el que llamamos a este m�todo obtendr� su propia conexi�n si la conexi�n era compartida.
��C�mo cierro la conexi�n con el servidor LDAP?
Para cerrar la conexi�n con el servidor, llamamos a Context.close() sobre todos los contextos originarios del contexto inicial que cre� la conexi�n. Debemos asegurarnos de que se ha completado toda la NamingEnumeration. Para aquellos contextos y objetos enumeraci�n que no van a permanecer m�s en el �mbito, el sistema de ejecuci�n Java los recolectar� como basura eventualmente, as� generar� el estado de limpieza que un close() habr�a hecho. Para forzar la recolecci�n de basura, podemos usar el siguiente codigo:
Runtime.getRuntime().gc(); Runtime.getRuntime().runFinalization();
��Es el contexto seguro para acceso multi-thread, o necesito bloquear/sincronizar los accesos
al contexto?
La respuesta depende de la implementaci�n. Esto es as� porque los interfaces Context y DirContext no especifican requerimientos de sincronizaci�n. La implementaci�n LDAP de Sun est� optimizada para accesos de un s�lo thread. Si tenemos varios threads accediendo al mismo ejemplar Context, cada thread necesita bloquear el Context cuando lo usa. Esto se aplica a cualquier NamingEnumeration que descienda del mismo ejemplar Context. Sin embargo, m�ltiples threads pueden acceder a diferentes ejemplares de Context (incluso aquellos que descienden del mismo contexto inicial) sin bloqueos concurrentes.
��Por qu� el proveedor LDAP ignora mis propiedades de entorno de seguridad si no configuro
la propiedad
Context.SECURITY_CREDENTIALS (
"java.naming.security.credentials") o la configuro con una cadena vac�a?
Si suministramos una cadena vac�a, un byte/char vac�o, o null a la propiedad de entorno Context.SECURITY_CREDENTIALS, ocurrir� una uni�n an�nima incluso si la propiedad Context.SECURITY_AUTHENTICATION fue configurada como "simple". Esto es porque para la autentificaci�n "simple", el LDAP requiere que las passwords no est�n vac�as. Si no se suministra una password, el protocole convierte autom�ticamente la autentificaci�n a "none".
��Por qu� sigo obteniendo un
CommunicationException cuando intento crear un contexto
inicial?
Podr�as estar hablando con un servidor que s�lo soporta LDAP v2. En la lecci�n Miscel�nea puedes ver un ejemplo de c�mo configurar el n�mero de versi�n.
��Estoy viendo un comportamiento extra�o. �C�mo puedo saber lo que est� ocurriendo realmente?
Intenta usar la propiedad de entorno "com.sun.jndi.ldap.trace.ber". Si el valor de esta propiedad es un ejemplar de java.io.OutputStream, la informaci�n de trazado sobre los buffers BER env�ada y recibida desde el proveedor LDAP se escribe en ese stream. Si el valor de la propiedad es null, no se escribir� salida de trazado.
Por ejemplo, el siguiente codigo envi�ra la salida de trazado a System.err:
env.put("com.sun.jndi.ldap.trace.ber", System.err);
��C�mo uso un mecanismo de autentificaci�n diferente, como Kerberos?
Primero, necesitamos tener las clases Java que soportan Kerberos y/o GSSAPI. Luego, necesitamos seguir las instrucciones de la lecci�n Securidad para poner diponible una implementaci�n de un mecanismo SASL para el proveedor LDAP.