blog de ezamudio

El viernes 12 de diciembre salió al fin la versión estable para producción de Tapestry 5. Voy a actualizar mis aplicaciones a la 5.0.18 y espero que ya no haya cambios de la 5.0.17; las notas de la nueva versión solamente indican dos correcciones y ningún cambio importante. La verdad es que ya se veía listo para producción desde hace como dos versiones.

Sito de Tapestry

Recientemente tuve algunos problemas actualizando una aplicación que utilizaba Tapestry 5.0.15 a 5.0.17 y tuve que buscar bastante para encontrar los problemas porque no están muy bien documentados algunos cambios, así que decidí publicar esta información aquí:

Lo más importante es que los campos de sus clases de páginas que anoten con @Property, no pueden tener un valor por default, ni pueden tener un método getter o setter. Si necesitan implementar uno de los dos métodos, van a tener que implementar ambos y quitar la anotación @Property. Si tienen un valor default, se lo deben asignar en algún otro lugar (un método anotado con @BeforeRender o hacer el getter que verifique si ya tiene algun valor y asignárselo en caso de que no, vigilando que si el valor puede ser fijado a nulo por el usuario, no hay que volver a ponerle nada, etc).

Les dejo esta anécdota a los programadores que visitan javamexico.com en busca de respuestas para ciertos problemas básicos y que a veces se ofuscan buscando algo muy concreto y pierden de vista el diseño general de su aplicación. La moraleja: si tienes un problema que parece algo difícil de resolver y/o la solución es muy tediosa de implementar, lo más probable es que alguien ya lo haya hecho antes. Y probablemente hay algún proyecto de software libre que contiene ya la manera de solucionar tu problema de manera sencilla. El principio DRY: Don't Repeat Yourself (en contraste con el síndrome NIH, Not Invented Here, que es tan común en muchas casas consultoras donde prefieren inventar el hilo negro en cada proyecto en vez de utilizar soluciones externas).
Hace poco me tomé un proyecto que originalmente tenía otra persona y al revisar su código me encontré varios horrores... un pequeño sitio web que en cada JSP tenía código Java para abrir una conexión a la base de datos, pero desde encontrar el Driver y pedir Connection, hasta cerrarla en el finally.

Recientemente tuve contacto con esta librería, que permite hacer cosas bastante interesantes. El objetivo central de la misma es permitir la manipulación de de clases de Java, directamente sobre los binarios, en tiempo de ejecución.
Dentro de su funcionalidad está la capacidad de leer y modificar las anotaciones que tiene un método o clase, siempre y cuando hayan sido definidas con Retention.CLASS o Retention.RUNTIME, es decir, anotaciones que se quedan en la clase compilada pero son ignoradas por la JVM al momento de utilizar la clase, o bien anotaciones que se quedan en la clase y son visibles en tiempo de ejecución.
Lo interesante es que se pueden ver las anotaciones y otras propiedades de una clase y sus métodos, antes de cargarla a la JVM, esto porque se lee el archivo .class directamente y se interpreta, e incluso se puede modificar. Por ejemplo, se pueden agregar anotaciones a una clase que no las tenía.
Incluso parece ser que se pueden modificar métodos, agregando código al principio o al final del mismo; crear clases al vuelo que heredan de clases existentes.

Esto salió a partir de una discusión en un foro de este sitio. Tengo dos proyectos de software libre registrados en Source Forge, y quiero hablar un poco acerca de ello. No tanto de los aspectos técnicos sino de las razones por las que liberé este software y algo de mi ideología al respecto del software libre.

Una parte muy tediosa del desarrollo en J2EE es cuando tenemos que crear un componente que utiliza servicios del contenedor y que necesitamos probar de manera unitaria. Una manera de hacer esto siempre es subir el componente al contenedor y ahi poner alguna interfaz para invocar todos sus métodos (ya sea que lo hagamos nosotros solos o con ayuda de un framework de pruebas unitarias como JUnit). Pero normalmente esto puede quitarnos mucho tiempo, ya que hay que tener un contenedor corriendo, que consume muchos recursos, y subir el componente ahi, para que tenga todo el contexto de los servicios que va a necesitar, tales como un DataSource, correo, EJB's, etc.

Hace poco escribí acerca de la característica principal de Spring, que es la inversión de control, en la cual se pasa el control de configurar y conectar objetos a Spring en vez de tener que hacerlo por medio de código o de una configuración propia (la cual hay que interpretar y para eso hay que escribir código).

En esta ocasión quiero hablar de otro aspecto de Spring, sencillo pero muy poderoso: el módulo de JDBC. Este módulo contiene varias características muy útiles, pero la más poderosa es el JdbcTemplate y su variante para Java 5, el SimpleJdbcTemplate.

En desarrollos J2EE generalmente se usa un contenedor como Tomcat, JBoss, Websphere, Weblogic, Glassfish, etc. La ventaja de estos contenedores es que ofrecen ya varios servicios que puede utilizar la aplicación que desarrollemos, por ejemplo datasources con manejadores de transacciones, servicio para envio de mail, autentificación de usuarios, logger, etc.

Pero qué pasa si necesitamos desarrollar una aplicación compacta, que no va a usar casi ninguno de estos servicios, que no tenga interfaz web por ejemplo, pero sí va a usar base de datos, mail, usuarios, etc? Qué pasa si el tiempo de arranque de la aplicación es importante?

Un poco fuera de tema en este sitio, dado que no es algo directamente relacionado con Java, pero sí es acerca de programación y de sistemas, así que...

Ya había leido algo al respecto de los "héroes" de Microsoft, creo que en el blog de Joel Spolsky, y me pareció ridículo, pero ahora ya recibí la publicidad de un evento que habrá aquí en México al respecto, con el hijo del Santo y toda la cosa...

Algo nuevo que apareció en Java 5 y no he visto que se le haga mucha promoción, cuando es algo muy útil, son los thread pools. El paquete java.util.concurrent define varias clases para usarse en ambientes de alta concurrencia (es decir, muchos threads realizando tareas simultáneamente, incluso teniendo acceso a los mismos recursos).
En este artículo describo las ventajas de los distintos tipos de thread pools, así como la manera de utilizarlos.

Antes
Un escenario común en algunas aplicaciones de alta concurrencia es por ejemplo estar recibiendo mensajes o peticiones de un sistema externo, o de usuarios del sistema, etc. Dichas peticiones se deben atender tan pronto como sea posible. Las opciones son:

1. Procesar cada tarea en un thread nuevo
2. Procesar todas las tareas de manera secuencial en un thread