Archivos para la categoría ‘J2EE’

Resolución de Cannot create JDBC driver of class » for connect URL ‘null’ en Tomcat

19 de junio de 2008

Durante el arranque de Tomcat, cuando la aplicación web lleva asociada una conexión a una base de datos, uno se puede encontrar un error con el siguiente mensaje

Cannot create JDBC driver of class » for connect URL ‘null’

Si aparece este mensaje, no se ha iniciado la conexión a la base de datos y, por lo tanto la aplicación no funciona.

Este error se puede dar cuando se realiza un cambio de versión, de un Tomcat 4.1.27/5.0.x a un Tomcat 5.5.x/6.0.x y no se tiene cuidado en adecuar las aplicaciones web a la nueva versión.

El problema viene del cambio de estructura del xml de configuración de los contextos, context.xml. Concretamente, el elemento Resource pasa de definirse en 2 elementos, Resource y ResourceParams, a uno solo, Resource, dónde los parámetros son atributos de este único elemento. A continuación se puede ver la diferencia entre las dos configuraciones para una conexión a una base de datos en postgres

Tomcat 4.1.27/5.0.x

	<Resource
        name="jdbc/BaseDeDatosPool"
        auth="Container"
        type="javax.sql.DataSource"
    />
    <ResourceParams name="jdbc/BaseDeDatosPool">
        <parameter>
            <name>driverClassName</name>
            <value>org.postgresql.Driver</value>
        </parameter>
        <parameter>
            <name>url</name>
            <value>jdbc:postgresql://127.0.0.1/mibasededatos</value>
        </parameter>
        <parameter>
            <name>username</name>
            <value>postgres</value>
        </parameter>
        <parameter>
            <name>password</name>
            <value></value>
        </parameter>
        <parameter>
            <name>maxActive</name>
            <value>20</value>
        </parameter>
    </ResourceParams>

Tomcat 5.5.X/6.0.x

<Resource name="jdbc/BaseDeDatosPool" auth="Container"
	type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
	url="jdbc:postgresql://127.0.0.1/mibasededatos"
	username="postgres" password="" maxActive="20"/>

Tomcat, al parsear el xml para inicializar el recurso, encuentra un error en el context.xml y la cadena de error que proporciona es Cannot create JDBC driver of class » for connect URL ‘null’, que en un principio puede despistar porque no resulta claro. Basta con adecuar el xml de configuración a la versión de Tomcat que se está utilizando para que deje de producirse.

El error se produce cuando el context.xml está malformado en la definición de recursos, por lo que se puede producir por otras causas diferentes de una cambio de versión, pero he centrado esta entrada en esta causa porque suele ser la más común

Configuración del juego de caracteres (charset) en una aplicación web en Tomcat

1 de abril de 2008

En este artículo se describen los pasos necesarios para la correcta configuración en UTF-8 de los juegos de caracteres una aplicación y los distintos componentes que intervienen en una arquitectura cliente/servidor de un servidor web. El procedimiento sería similar en el caso de que el juego de caracteres elegido fuera el ISO8859-1. Para la configuración de este artículo se ha utilizado el servidor web Tomcat versión 6.0.16 y Postgresql como motor de base de datos.

A continuación se muestra la figura con un esquema de todos los componentes. En esta figura se marcan los distintos componentes con números (en rojo) para poder referenciarlos en las descripciones que siguen.

Codificacion de Caracteres

Configuración del Servidor Web (Tomcat)

Se puede modificar el charset de la máquina virtual donde se ejecute el servidor, añadiendo como opción de ejecución en JAVA_OPTS el parámetro -Djava.file.encoding=UTF-8 (0). Si se trata del Tomcat, se debe añadir al fichero catalina.sh o catalina.bat según el sistema operativo.

Este valor no se tiene en cuenta en la máquina virtual de Sun 1.4.x, porque al parecer se trata de una propiedad de solo lectura en numerosas máquinas virtuales (leido en los foros del Tomcat). Sí parece activarse en la máquina virtual de Sun 1.5.x.

En principio no parece necesario modificar el charset de la máquina virtual, porque ninguna prueba realizada demuestra que se tenga en cuenta para las operaciones de codificación de caracteres en un intercambio cliente/servidor. En cambio, sí que afecta a otros aspectos de las aplicaciones, como la codificación de caracteres utilizada para escribir en el log por la librería log4j.

Si por alguna razón se produjera algún problema en la codificación de caracteres, se puede intentar modificar este parámetro para encontrar la solución. Si se hace, puede que sea necesario modificar la codificación de caracteres del elemento appender del log4j.

Para fijar este parámetro:

  • En Windows: Edita el fichero %CATALINA_HOME%\bin\catalina.bat y añade la siguiente línea:
rem ----- Execute The Requested Command -----
echo...
echo...
set...
set JAVA_OPTS=%JAVA_OPTS% -Djava.file.encoding=UTF-8
  • En Linux: Edita el fichero $CATALINA_HOME/bin/catalina.sh y añade al principio la siguiente línea.
JAVA_OPTS="$JAVA_OPTS -Djava.file.encoding=UTF-8

Para modificar la configuración del log4j: Añadir el atributo encoding del elemento appender utilizado, asignándole el valor ISO8859-1, en el fichero de configuración:

  • En xml, añadir dentro del elemento appender:
 
  • En properties:
log4j.appender.file.encoding=ISO8859-1

El navegador efectúa un GET sobre el servidor.

En un petición de tipo GET, los parámetros se encuentran en la URL (query string). Para que se ejecute correctamente, los parámetros hay que codificarlos correctamente al construir la url del GET y luego que el servidor los decodifique correctamente antes de pasárselos al correspondiente Servlet.

  • (1) La codificación de los parámetros en la url se debe realizar al construir el html de cada página. Para ello se pueden utilizar el método encode de la clase java.net.URLEncoder al que se le suministra como parámetro el juego de caracteres (UTF-8)
  • (2) La decodificación de los parámetros de la URL se realiza en el conector de Tomcat, tanto el 8080 como el de ssh 443, configurado en el archivo server.xml mediante
 

El navegador efectúa un POST sobre el servidor.

La codificación de los parámetros se realiza en el navegador. Para que el navegador sepa en qué juego de caracteres tiene que codificar los parámetros del POST que envía, el html tiene que tener la siguiente cabecera (3), que se tiene que incluir en el jsp de incluya las cabeceras (4)

 

Al recibir los parámetros de un POST, el servlet que se encarga de recibir la petición tiene que fijar el juego de caracteres en el que llega la petición. En el caso de una aplicación que usa Struts o cualquier aplicación web que utilice el modelo MVC en el que todas las peticiones pasan por el elemento Controller, esta operación se debe realizar en dicho elemento, en el caso de Struts el servlet que extienda al ActionServlet (5).

request.setCharacterEncoding("UTF-8");

Precompilación de los JSP

Los Jsp se pueden precompilar opcionalmente para convertirlos en servlets. En este caso, es necesario precompilarlos utilizando el juego de caracteres que se utiliza en la máquina donde se están editando, que no suele ser UTF-8, sino ISO8859-1. Esto se hace para que los archivos precompilados mantengan el juego de caracteres en el que fueron escritos a la hora de convertirse en servlets. Este juego de caracteres no es que utiliza por defecto la precompilación (UTF-8). Por lo tanto es necesario especificarlo (9):

  • En el caso de que los compile el servidor web, Tomcat, según vaya necesitando estos jsp, se utiliza el parámetro javaEncoding que se le debe suministrar al servlet encargado de la precompilación, JspC o Jikes en archivo web.xml general de Tomcat, servlet org.apache.jasper.servlet.JspServlet.
javaEncoding
ISO-8859-1
  • En el caso de que los jsp se precompilen mediante la tarea de ant jasper2, es necesario suministrarle a esta tarea el parámetro javaEncoding:
 

Acceso a los datos

Los datos deben estar guardados en una base de datos acorde con el juego de caracteres que se pretenda usar (6). UNICODE en el caso de UTF-8 para Postgresql. Este juego de caracteres se especifica al crear la base de datos.

Además, para el acceso a la base de datos, se debe configurar el driver para que utilice el juego de caracteres correctos en el intercambio de datos (7). Esta configuración se realiza en el archivo context.xml. Para el caso de PostgreSQL parece que no es necesario especificar el juego de caracteres para una base de datos UNICODE.

Visión correcta en el navegador de la respuesta

Para que el navegador muestre correctamente el contenido del html generado (8.1), necesita saber el juego de caracteres del html. Este proceso se realiza al decodificar la respuesta del servidor de acuerdo a la cabeceras HTTP de respuesta de tipo de contenido, Content-Type (8.2) según se puede ver en el siguiente ejemplo de cabecera HTTP de respuesta:

HTTP/1.x 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=UTF-8
Content-Length: 2540
Date: Wed, 30 Mar 2008 19:53:00 GMT

Para que esta cabecera HTTP se incluya en la respuesta, se debe incluir en el código lo siguiente, dependiendo de si se trata de un servlet o un jsp:

  • (8.3) JSP. En un jsp que se incluya en todos los html de respuesta, hay que incluir
&lt;%@ contentType="text/html"; charset="UTF-8" %&gt;
  • (8.4) Servlet. Al enviar la respuesta:
response.setContentType("text/plain; charset=UTF-8");
java.io.PrintWriter out = response.getWriter();
out.print(responseStr);
response.flushBuffer();
out.close();

Causas y solución de java.lang.OutOfMemoryError: PermGen space failure

28 de marzo de 2008

La memoria de la Máquina Virtual se divide en varias regiones. Una de estas regiones es el PermGen, el área de memoria utilizada para, entre otras cosas, guardar el metadata de las clases como los atributos y sus tipos de datos, métodos etc. Esta memoria es de tipo non-heap. Las instancias de las clases se cargan en la memoria de tipo heap, a la que se van añadiendo y eliminando las instancias de las clases según se van utilizando y eliminándose por el recolector de basura (Garbage Collector, en adelante GC).

No vamos a entrar en el mecanismo de la carga y eliminación de clases en java porque excede este artículo, pero sí lo comentaremos brevemente para poder entender el porqué de la excepción OutOfMemoryException: para que una clase pueda ser eliminada por el recolector de basura (GC), es necesario que no esté referenciada por ninguna otra clase. Para que se pueda eliminar la memoria ocupada por una clase en el espacio PermGen, es necesario además que se elimine el classloader que cargó la clase.

El valor por defecto del espacio PermGen es de 64 Mb en la máquina virtual (VM) de Sun. Este valor es suficiente normalmente para las aplicaciones que corren de forma independiente. En el caso de una aplicación que corra en un servidor web tipo Tomcat o un servidor de aplicaciones, hay casos en los que este valor no es suficiente.

En primer lugar, es posible que la aplicación necesite más espacio por su propia arquitectura. Las librerías Spring e Hibernate son librerías grandes, que cargan muchas clases y además hacen uso de proxies y carga dinámica de clases que hacen uso del espacio PermGen por lo que puede que los 64Mb no sean suficientes. Este caso se da cuando la excepción con el error se produce nada mas arrancar el servidor web o de aplicaciones o al acceder a la aplicación. Para solventar este problema bastará con aumentar el tamaño máximo de la memoria de tipo PermGen según veremos más adelante.

En segundo lugar, la causa más probable de una excepción java.lang.OutOfMemoryError: PermGen space failure se produce cuando la aplicación se reinstala en el servidor sin reiniciar el servidor. La forma de reinstalar las aplicaciones es eliminando el classloader que cargó la aplicación por primera vez y creando un nuevo classloader para la nueva instancia de la aplicación. En teoría, esto proporciona una forma limpia de reinstalar aplicaciones, pero si el servidor web o de aplicaciones guarda una referencia al classloader antiguo, se produce una fuga de memoria (memory leak) y el resultado es que tendremos las clases de la aplicación cargadas dos veces en memoria. Es cuestión del número de recargas y de la memoria gastada por la aplicación el que se produzca la excepción  java.lang.OutOfMemoryError: PermGen space failure. En este caso no basta con aumentar el tamaño máximo de la memoria, ya que esto sólo retrasaría el problema a unas cuantas reinstalaciones más. En este caso la única solución consiste en averiguar la causa de la fuga de memoria. Esto también excede el contenido de este artículo, aunque lo intentarmos tratar con profundidad en otra ocasión. Por el momento sólo proporcionamos un enlace muy interesante, aunque en inglés, acerca de posibles causas de fugas de memoria en java: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

Por último, a continuación incluimos el argumento que es necesario incluir al arrancar la máquina virtual para especificar el tamaño de esta región PermGen en Mb, XX:MaxPermSize=128m para el tamaño máximo y XX:PermSize=128m para que la máquina virtual ya arranque con este tamaño y no tenga que reservar más espacio en tiempo de ejecución.