Aquí os dejamos un tutorial para exportar librerías GWT a javascript

Lo primero es encontrar un proveedor que permita el envío de sms mediante una conexión a su servidor. Puede que existan aún aquellas páginas donde era gratuito enviar un sms. Sin embargo la fiabilidad de entrega de estos proveedores, unido a que sólo permiten enviar a través de una página web y no desde un programa java y que suelen estár asociados al envío de publicidad no hacen de esta solución una solución aceptable.

Un proveedor de sms sirve de intermediario entre nuestra aplicación Java y los operadores de telefonía móvil. La misión del programa Java será por tanto conectarse de algún modo al proveedor elegido (HTTP, SMTP…) y pasarle los datos del sms en algún formato (con los propios parámetros de HTTP, con un xml…).

Después de buscar entre varios proveedores, nos hemos quedado con la pasarela de envío de sms de Altiria. El envío de sms se realiza con este proveedor mediante una petición POST a su servidor con los datos del sms que se quiere enviar como parámetros de la propia petición, siendo los más importantes el contenido del sms y los destinatarios. Se puede encontrar el documento de especificaciones de la conexión también en su web (Documento de especificaciones).

Queremos resaltar que el para que el ejemplo que ponemos a continuación funcione y envíe un sms, es necesario ponerse en contacto con Altiria y contratar un bono de envío de sms que permita la conexión a su pasarela de envío. El ejemplo sirve para ilustrar lo fácil que sería el envío del sms una vez contratado el bono.

Ya tenemos el proveedor y el mecanismo de envío (HTTP). Ya sólo queda implementar esta conexión HTTP en nuestro programa Java. Para ello necesitamos un cliente HTTP para realizar la conexión. Hemos elegido la librería HTTP de Jakarta, (HttpClient) que debe estar presente en el classpath de nuestra aplicación. El siguiente código realiza la conexión enviando los parámetros del sms.

//Se inicia el objeto HTTP
HttpClient client = new HttpClient();
client.setStrictMode(true);
//Se fija el tiempo máximo de espera de la respuesta del servidor
client.setTimeout(60000);
//Se fija el tiempo máximo de espera para conectar con el servidor
client.setConnectionTimeout(5000);
PostMethod post = null;
//Se fija la URL sobre la que enviar la petición POST
 
//Como ejemplo se supone www.pasarela_push_altiria.com/post/sms
post = new PostMethod("http://www.pasarela_push_altiria.com/post/sms");
 
//Se fija la codificación de caracteres en la cabecera de la petición
post.setRequestHeader("Content-type", "application/x-www-form-urlencoded; charset=UTF-8");
 
//Se crea la lista de parámetros a enviar en la petición POST
NameValuePair[] parametersList = new NameValuePair[3];
parametersList[0] = new NameValuePair("dest", "34600111222");
parametersList[1] = new NameValuePair("dest", "34600111333");
parametersList[2] = new NameValuePair("msg", "Mensaje de prueba");
 
//Se rellena el cuerpo de la petición POST con los parámetros
post.setRequestBody(parametersList);
int httpstatus = 0;
String response = null;
 
try {
//Se envía la petición
httpstatus = client.executeMethod(post);
//Se consigue la respuesta
response = post.getResponseBodyAsString();
}
catch (Exception e) {
//Habrá que prever la captura de excepciones
return;
}
finally {
//En cualquier caso se cierra la conexión
post.releaseConnection();
}
 
//Habrá que prever posibles errores en la respuesta del servidor
if (httpStatus!=200){
return;
}
else {
//Se procesa la respuesta capturada en la cadena ‘‘response’’
}

Este código se traduce en el envío de un sms con el texto “Mensaje de Prueba” a los móviles 34600111222 y 34600111333.

Además, hay que tener en cuenta el tipo de memoria sobre el que se quiere actuar: heap, non-heap (PermGen). Los valores por defecto que se dan corresponden a máquina virtuales de Sun, y son orientativos, porque pueden cambiar entre versiones de la máquina virtual. Los parámetros son los siguientes, fijándose a 128Mb.

• -Xms128m: Tamaño de inicio de la máquina virtual de Java a 128Mb. El valor por defecto son 64Mb. Si se aumenta este valor, se elimina el tiempo que se tardaría en aumentar el tamaño en memoria de la máquina virtual si se llegara el caso de que se necesitara más memoria, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria.
• -Xmx128m: Tamaño máximo de la máquina virtual de Java a 128Mb.  El valor por defecto son 128Mb. Si la aplicación supera el tamaño máximo de memoria que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError.  No conviene asignar a este parámetro el máximo de la memoria de la máquina porque si ya no queda memoria física disponible (por la que usa el sistema operativo u otras aplicaciones) se pueden producir escrituras en memoria asignada a otros programas y provocar un auténtico lío.
• -XX:PermSize=128m: Tamaño de inicio de la memoria de tipo PermGen a 128Mb. Arrancar la máquina virtual con un valor superior al por defecto agiliza la carga de aplicaciones, sobre todo en el caso de aplicaciones que hagan uso intensivo de este tipo de memoria (Spring, Hibernate…)
• -XX:MaxPermSize=128m: Tamaño máximo de la memoria de tipo PermGen a 128Mb. El valor por defecto son 64Mb. Si la aplicación supera el tamaño máximo de memoria para este tipo que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError: PermGen space. El valor necesario para este parámetro siempre suele ser menor que el de la memoria de tipo heap.

Si se quiere especificar un valor distinto de 128Mb, que se utiliza para todos los parámetros como ejemplo para simplificar, bastaría con sustituir el valor 128 del parámetro con el que se desee, siempre que sean múltiplos de 2 (64, 128, 256, 512, 768, 1024, 2048…)

Conocidos los tipos de memoria y los parámetros que los controlan, ahora viene la pregunta, ¿cómo especifico estos valores para mi aplicación? La respuesta es la misma para todos los casos: Los valores se especifican como parámetros en el arranque de la máquina virtual que ejecutará la aplicación. La diferencia estribará en cómo se arranca la aplicación: con un script, desde línea de comandos, mediante ant…

A continuación se dan distintos ejemplos de modificación de la memoria de distinta forma. No es necesario especificar todos los parámetros, se pueden especificar todos o ninguno (y se tomarían los valores por defecto)

Línea de comandos

• Ejecución de un jar: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  -jar example.jar
• Ejecución de una clase: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  com.programacionenjava.examples.MemoryExample

Ant

<java classname=”com.programacionenjava.examples.MemoryExample” fork=”yes” spawn=”true”>
<jvmarg value=”-Xms128m”/>
<jvmarg value=”-Xmx512m”/>
<jvmarg value=”-XX:PermSize=128m”/>
<jvmarg value=”-XX:MaxPermSize=128m”/>
<classpath refid=”execution.classpath”/>
</java>

Script

Si el arranque de la máquina virtual se produce en un script, hay que editar el script y añadir estos parámetros en la sentencia de arranque. El siguiente ejemplo muestra cómo añadir estos parámetros en el script de arranque de un Tomcat.

• En Windows: set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m
• En Linux: JAVA_OPTS=”$JAVA_OPTS -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m”

Por último, recordamos que resolver el problema de una excepción de tipo java.lang.OutOfMemoryError simplemente aumentando el tamaño de la memoria virtual puede retrasar el problema pero no evitarlo si el problema es una fuga de memoria. Puedes encontrar más información aquí.

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.

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

<%@ contentType="text/html"; charset="UTF-8" %>

• (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();

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.