Aquí están los problemas que nos podríamos encontrar cuando intentamos ejecutar un programa compilado satisfactoriamente y que usa clases JNDI.

Problema: Obtenemos un error NoClassDefFoundError cuando ejecutamos nuestro programa.

Causa: No hemos incluido las clases JNDI (jndi.jar) en nuestro classpath, o no instalamos apropiadamente las clases JNDI.

Solución: El Java 2 SDK, v1.3 ya incluye las clases JNDI por eso si estamos usando esta versión no deberíamos obtener este error.

Si no estamos usando Java 2 SDK, v1.3, entonces la forma de incluir las clases JNDI en nuestro entorno de ejecución depende de nuestro entorno. Si estamos usando el Java 2 SDK, v1.2, debemos asegurarnos de que jndi.jar está en el directorio JAVA_HOME/jre/lib/ext, donde JAVA_HOME es el directorio que contiene el Java Runtime Environment (JRE). Observa que en algunas plataformas, existen directorios separados para el JRE y el SDK. Debemos asegurarnos de que los ficheros Jars del JNDI están instalados en ambos directorios jre/lib/ext. Si estámos usando el intérprete java del JDK 1.1, debemos añadir los ficheros JARs a nuestra variable de entorno CLASSPATH o a la opción -classpath de nuestra línea de comandos java.

Para un applet, necesitamos hacer que las clases del JNDI y del proveedor de servicios estén disponibles para el applet (por ejemplo, añadiéndolas a la opción archive).

Problema: Obtenemos un NoInitialContextException.

Causa: No especificamos qué implementación usar para el contexto inicial. Especificamente, la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY no se configuró con el nombre de la clase de la factoría que creará el contexto inicial. O, no hicimos disponibles para el programa las clases del proveedor de servicios nombradas por Context.INITIAL_CONTEXT_FACTORY.

Solución: Seleccionamos la propiedad de etorno Context.INITIAL_CONTEXT_FACTORY apropiadamente con el nombre de la clase de la implementación del contexto incial que estamos usando. Puedes ver la sección Lo básico para más detalles.

Si la propiedad fue configurada, entonces debemos asegurarnos de que el nombre de la clase se tecleo correctamente, y que la clase nombrada está disponible para nuestro programa (o en su classpath o instalada en el directorio jre/lib/ext del JRE). El Java 2 SDK, v1.3 incluye proveedores de servicio para LDAP, COS naming, y el registro RMI. Todos lo otros proveedores de servicios deben instalarse y añadirse al entorno de ejecución.

Problema: Obtenemos una CommunicationException, indicando "connection refused."

Causa: El servidor y el puerto indentificados por la propiedad de entorno Context.PROVIDER_URL no están siendo servidos por el servidor. Quizás alguien haya desactivado la máquina en la que se está ejecutando el servidor. O quizás, nos hemos equivocado al teclear el nombre o el puerto del servidor.

Solución: Chequear que hay un servidor ejecutándose en ese puerto, y rearrancar el servidor si es necesario. La forma de realizar esta tarea depende del servidor LDAP que estemos usando, normalmente, hay disponible una consola o herramienta administrativa que podemos usar para administrar el servidor. Podríamos usar esa herramienta para verificar el estado del servidor.

Problema: El servidor LDAP responde a otras utilidades (como su consola de administración) pero parece no responder a las peticiones de nuestro programa.

Causa: El servidor no responde a peticiones de conexión LDAP v3. Algunos servidores (especialmente servidores públicos) no responden correctamente a LDAP v3, ignorando las peticiones en lugar de rechazarlas.

También, algunos servidores LDAP v3 teinen problemas al manejar un control que el proveedor de servicios de Sun envía automáticamente y frecuentemente devuelven un código de fallo específico del servidor.

Solución: Intentemos configurar la propiedad de entorno "java.naming.ldap.version" a "2". El proveedor de servivio LDAP por defecto intenta conectarse a un servidor LDAP usando el LDAP v3; si este falla, intenta usar LDAP v2. Si el servidor silenciosamente ignora la petición v3, entonces el proveedor asume que la petición funcionó. Para trabajar con dichos servidores, debemos seleccionar explícitamente la versión del protocolo para asegurarnos un comportamiento apropiado del servidor.

Si el servidor es un servidor v3, intentemos configurar la siguiente propiedad de entorno antes de crear el contexto inicial.

Esto desactiva el control que proveedor LDAP envía automáticamente.

Problema: El programa se cuelga.

Causas: Algunos servidores (especialmente los públicos) no quieren responder (incluso ni respuestas negativas) si intentamos realizar una búsqueda que podría generar demasiados resultados o que requiera que el servidor examine demasiadas entradas para poder generar una respuesta. Dichos servidores están intentando limitar la cantidad de recursos que gastan en pre-peticiones básicas.

O, estámos intentando usar Secure Socket Layer (SSL) contra un servidor/puerto que no lo soporta, y viceversa (es decir, estámos intentando usar un socket normal para hablar con un puerto SSL).

Solución: Si nuestro programa se cuelga es porque el servidor está intentando restringir el uso de sus recursos, entonces repetimos nuestra petición usando una consulta que devuelva un sólo resultado o unos pocos resultados. Esto nos ayudará a determinar si el servidor está vivo. Si es así, podemos abordar nuestra consulta inicial y reenviarsela.

Si nuestro programa se cuelga por problemas SSL, necesitamos encontrar si el puerto es un puerto SSL y luego configurar la propiedad de entorno Context.SECURITY_PROTOCOL de la forma apropiada. Si el puerto es un un puerto SSL, esta propiedad debería ser "ssl". Si no es un puerto SSL, está propiedad no debería estar configurada.

Problema: Obtenemos una NameNotFoundException.

Causas: Cuando inicializamos el contexto inicial para el LDAP, suministramos un nombre raíz-distinguido. Por ejemplo, si configuramos la propiedad de entorno Context.PROVIDER_URL para el contexto incial a "ldap://ldapserver:389/o=JNDITutorial" y subsecuentemente suministramos un nombre como "cn=Joe,c=us", entonces el nombre completo que pasamos al servicio LDAP fue "cn=Joe,c=us,o=JNDITutorial".

Si este era realmente el nombre que queríamos, deberíamos chequear nuestro servidor para asegurarnos de que existe dicha entrada.

También, el Netscape Directory Server devuelve este error si suministramos un nombre distinguido incorrecto para propósitos de autentificación. Por ejemplo, el proveedor LDAP lanza una NameNotFoundException si configuramos la propiedad de entorno Context.SECURITY_PRINCIPAL como "cn=Admin, o=Tutorial", y "cn=Admin, o=Tutorial" no es una entrada del servidor LDAP. El error correcto devuelto por el Netscape Directory Server realmente debería ser algo relacionado con la autentificación en vez de "name not found."

Solución: Verificar que el nombre que suministramos es una entrada existente en el servidor. Podemos hacer esto listando los contextos padres de la entrada o usando alguna otra herramienta como la consola de administración del servidor de directorio.