Las ventajas de utilizar GWT para desarrollar código javascript de calidad es que el programador no tiene por qué ser experto en javascript, conocer particularidades de cada navegador, empaquetamiento de javascript, ofuscación, dependencias entre librerÃas, etc.
Aquà os dejamos un tutorial para exportar librerÃas GWT a javascript
En esta entrada os mostraremos cómo enviar sms desde una aplicación Java. Seguro que esta funcionalidad os la ha pedido algún cliente que querÃa integrar directamente en vuestra aplicación la posibilidad de enviar un sms en alguna situación como comunicarse con sus propios clientes, enviar una alerta en determinadas ocasiones, etc…
Lo primero es encontrar un proveedor que permita el envÃo de sms mediante una conexión a su servidor. Un proveedor para enviar 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.
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.
En Java, hay varios parámetros para controlar el tamaño inicial y el tamaño máximo que puede tomar la máquina virtual.
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.
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
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.
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Ã.
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.
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:
rem ----- Execute The Requested Command ----- echo... echo... set... set JAVA_OPTS=%JAVA_OPTS% -Djava.file.encoding=UTF-8 |
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:
log4j.appender.file.encoding=ISO8859-1 |
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.
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"); |
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):
javaEncoding ISO-8859-1 |
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.
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:
<%@ contentType="text/html"; charset="UTF-8" %> |
response.setContentType("text/plain; charset=UTF-8"); java.io.PrintWriter out = response.getWriter(); out.print(responseStr); response.flushBuffer(); out.close(); |
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.