Tynamo, viejas novedades.

Estoy preparando el anuncio de un nuevo módulo de Tynamo  y esto me da un buen pie para hablar del estado de Tynamo en general.

Desde hace un tiempo ya que Tynamo ha dejado de ser solamente un framework orientado a CRUD, de a poco hemos ido incoporando pequeños módulos orientados principalmente a integrar Tapestry5 con otras librerías de terceros o a proveerlo de pequeñas funcionalidades extra. Todo esto con el fin de armar nuestro propio full stack web framework, pero siempre manteniendo la independencia y simplicidad de los módulos por si se quieren usar por separado.

Al día de hoy nuestros módulos son:

  • tapestry-conversations
  • tapestry-exceptionpage
  • tapestry-hibernate-seedentity
  • tapestry-jbpm
  • tapestry-jpa
  • tapestry-jpa-seedentity
  • tapestry-model
  • tapestry-resteasy
  • tapestry-security
  • tapestry-watchdog
  • tynamo-federatedaccounts

tapestry-model es el módulo principal de Tynamo, ya vamos por la segunda versión y está en producción desde hace un tiempo. De la mano de la Tapestry 5.2 han llegado muchas nuevas features, una de las principales es la validación usando el estandar JSR303, gracias a este estandar la integración de otros proveedores JPA distintos de Hibernate se hace mucho más fácil. Pierce T. Wetter, el autor original de tapestry-jpa se ha unido al equipo de Tynamo y junto con Piero Sartini, quien se ha encargado del módulo tapestry-model-jpa, han logrado que finalmente Tynamo sea completamente independiente de Hibernate.

tapestry-security era el módulo más esperado y en poco tiempo se ha convertido en el más popular. tapestry-security es una integración de Tapestry5 con Shiro. Venimos trabajando en un módulo de seguridad que sea independiente de Spring desde la época de Trails 1.2 cuando Shiro era conocido como JSecurity, hemos acompañado la evolución y los cambios de nombre de Shiro (Jsecurity, Ki , Shiro) y hemos ido madurando el código con ellos. Nuestra primera implementación era un port de tapestry-acegi, basicamente era el mismo código pero en lugar de usar Acegi usábamos Shiro. La solución era muy básica con una sola anotación de seguridad (@Secured) y una estructura de contribuciones a los filtros no muy simple (aunque aún así muy dinámica y flexible) que imitaba las funcionalidades de Acegi sin aportar nada nuevo. Gracias a la contribución de Valentin Erastov (aka: xibyte), rápidamente ampliamos la cantidad y variedad de las anotaciones de seguridad manteniendo esa potente simplicidad que diferencia a Shiro de Acegi. Con lo aprendido en el desarrollo de tapestry-security fuimos a hablar con la gente Shiro. Nos recibieron con los brazos abiertos, Kalle (mi co-lead) se hizo commiter de Shiro y las anotaciones que habíamos creado para tapestry-security pasaron a formar parte del core de Shiro.

Además, Kalle también ha sido nombrado commiter en Tapestry, así que ahora tenemos una pata dentro de Tapestry y otra dentro de Shiro lo que nos deja en una excelente posición para continuar mejorando nuestros módulos.

 

 

 

 

Tynamo finalista del Vodafone Mobile Clicks 2010


Mobivery se ha presentado al
Vodafone Mobile Clicks con MALCOM, un servicio para gestionar de manera integral el ciclo de vida de una aplicación móvil, y ha sido seleccionada como finalista española. La final tendrá lugar en en Amsterdam los próximos 23 y 24 de septiembre 2010, y competirá con otras start-ups de de Holanda, Portugal y Reino Unido

MALCOM está implementado utilizando frameworks y herramientas del stack de desarrollo de Amneris: Tynamo (obviamente), Tapestry 5, Hibernate, RestEASY, Shiro, etc.

Es un pequeño orgullo y me llena de satisfacción poder presentar en este tipo de foros una aplicación Java, liviana, basada en Tynamo/Tapestry y de alguna manera ayudar a difundir un poco el uso de estos frameworks.

No puedo ni empezar a contarles lo bien que nos vendría la "ayuda" monetaria para la continuidad del proyecto. Así que, pasen y voten por su producto favorito: http://www.<wbr>vodafonemobileclicks.com/vote/
Los votos contarán por un 20% en la decisión final. Todos los votos son de ayuda.


.

tapestry-exceptionpage 0.0.1 released!

El equipo de Tynamo viene haciendo ya varias releases este año (de las que ya tendría que haber hablado, perdón).

En abril hemos liberado tapestry-exceptionpage un pequeño módulo para Tapestry5 que viene a ser la alternativa Tapestry a está vieja y conocida configuración xml.

<error-page><exception-type>java.lang.Throwable</exception-type>   <location>/generalError.jsp</location></error-page>

Tapestry envuelve convenientemente dentro de una ComponentEventException cualquier exception no atrapada y en modo de desarrollo muestra una muy util página de error, pero desafortunadamente eso hace imposible el uso de la configuración estándar de páginas de error en el archivo web.xml. Tampoco es que sea la gloria configurar todas las páginas de error en un mega xml, pero según el caso puede resultar útil.

tapestry-exceptionpage permite contribuir mapeos entre el tipo de las excepciones y las páginas de error usando directamente código Java (Tapestry-IOC). Este mecanismo de configuración es mucho menos "verborrágico" que el estándar de web.xml y mucho más flexible ya que permite especificar mapeos distintos para contextos diferentes.

Para más información al respecto consultar la pequeña guía de tapestry-exceptionpage.

Kudos to Kalle.

Trails is dead, long live Tynamo!

Repitiendo un poco lo que mi compañero Kalle Korhonen comentó en la lista de desarrollo y en la web de Trails: Trails is dead, long live Tynamo!

El titular es un poco amarillista intentando atraer un poco de atención, pero la verdad es que Trails no está muerto, sino que Trails 1.x está en "maintenance mode" y Trails 2 (la nueva versión basada en Tapestry5) ha sido renombrado a Tynamo.

Un resumen (editado de la lista de correos) de las razones del cambio de nombre:

En segundo plano (en realidad en la lista de desarrolladores) hemos estado discutiendo de cual debería ser nuestra estrategia respecto de Tapestry5. Hace más de un año "perdimos" el dominio trailsframework.org (esto es bastante largo de explicar, pero la versión corta es que los committers actuales nunca tuvimos posesión del dominio) y desde ese entonces estamos analizando varias alternativas acerca de como lidiar con esto. Hace un par de meses finalmente decidimos que lo más fácil para nosotros sería renombrar el proyecto y relanzar Trails2 con un nuevo nombre: Tynamo
Esto todavía esta sin publicitar, pero la mudanza ya está en camino, el código ya ha sido trasladado al nuevo repositorio y todos los módulos y paquetes han sido renombrados.
Creemos que hay una gran posibilidad de tener preparada la release inicial de Tynamo para antes de fin de año. Cuando la tengamos haremos el anuncio formal correspondiente.

Así que ya pueden venir a visitarnos a http://tynamo.org/ (esta vez somos los dueños del dominio). El site está prácticamente vacío porque estamos trabajando en él y preparando las releases. Las snapshots ya están disponibles en: http://ci.repository.codehaus.org/org/tynamo/
El repositorio ya está completamente migrado (con log histórico completo), el nuevo dominio funcionando y nuestros continuous integration builds ejecutándose exitosamente, así que estamos nuevamente en carrera con Tynamo. Para el momento en el que anunciemos el proyecto Tynamo a una audiencia más grande, ya deberíamos tener varios nuevos módulos preparados para el release como así también documentación decente (este nunca fue nuestro fuerte) y ejemplos que los acompañen.

Como adelanto puedo comentar que tendremos un nuevo módulo para Envers y uno para RESTeasy. También puedo adelantar que haremos open source la integración con jBPM (tapestry5-jbpm y tynamo-jbpm) que teníamos desarrollada en la empresa.

Como comentaba antes, la versión basada en Tapestry4 está en "maintenance mode" pero nosotros seguimos dando soporte en la lista de usuarios y si se encuentran problemas serios los solucionaremos.

Los desarrolladores queremos agradecer a Codehaus y especialmente a Ben Walding por pacientemente acompañarnos en la transición dándonos soporte y solucionándonos numerosos problemas.

Espero poder comunicarles más novedades pronto.

Stay tuned!


.

Cambios en en el stack de Amneris (Tiempo de Balances 1)

El stack de Amneris ha sufrido grandes cambios en los últimos meses. Tenemos 3 nuevas incorporaciones, 2 jubilaciones, y un retiro por invalidez :)

En primer lugar damos la bienvenida oficial a Tapestry5 que si bien ya hacia tiempo que estaba dando vueltas por los alrededores, no había sido debidamente presentado. La adopción de Tapestry5 deja a Tapestry4 relegado al mantenimiento de aplicaciones legacy.

De la misma manera que Tapestry4, se retira con honores Trails 1.x, que ya ha cumplido su ciclo, para dejar paso al todavía en desarrollo Trails 2 basado en Tapestry5. Trails 2 está todavía muy lejos de ofrecer todas las prestaciones que ofrece se hermano menor, pero no tiene sentido seguir invirtiendo tiempo en Trails 1 cuando el framework principal en el que se basa está ya completamente obsoleto. Esto conlleva también el esfuerzo de ir migrando de a poco todos nuestros otros frameworks y librerías que se basaban en Trails.

La incorporación de Tapestry5 al stack desplaza también a Spring como framework de IoC por defecto del stack. Spring (a mi parecer) a dejado de innovar en el espacio de la IoC y en estos momentos hay ofertas muchísimo más interesantes como Guice y Tapestry5 IoC. La cantidad de código basado en Spring IoC que tenemos es tal que reemplazarlo no será tarea fácil, pero de ahora en adelante Spring no será la primer alternativa a la hora de implementar IoC en nuestras aplicaciones. Trails2 será completamente independiente de Spring. Completamente compatible SI, pero independiente al fin.

Ya he mencionado la incorporación de Tapestry5 y Trails2 pero el gran fichaje de la temporada es Magnolia CMS. Trails nos estaba quedando un poco chico para según que cosas y necesitábamos incorporar una solución robusta que nos garantizara estabilidad pero con flexibilidad. Magnolia se usa detrás de los sitios de InfoQ y JBoss.org, así que si puede con la carga de esos dos sitios, podrá manejar nuestra carga sin ningún inconveniente. Otra gran característica de Magnolia es la implementación de Java Content Repository (JCR - JSR-170) que nos da una gran tranquilidad respecto de que nuestros datos son almacenados siguiendo un estándar abierto para la gestión de contenido.

Bienvenidos Magnolia, Tapestry5 y Trails 2!

Extrañando a los recolectores de basura de mi barrio.

Me pasé toda la semana pasada trabajando con ObjectiveC, prestando muchísima atención al código, especialmente a la declaración de variables, para no ir dejando memory leaks desparramados por ahí. A buena hora me vengo a enterar que ObjetiveC es muy sensible a los memory leaks. Para un Java adicto GC dependiente como yo, esto de andar contando la cantidad de referencias a un objeto para luego "destruir" (liberar) las variables a mano, es una experiencia completamente nueva.

Después de una semana con ObjetiveC el sábado retome el trabajo con Trails, preparando lo que será el codebase para Trails 2.0.x (el ".x" del final es a propósito para que no parezca un buzzword). La nueva versión de Trails estará basada en Tapestry5 y como este trae su propio contenedor IoC la mayor parte del trabajo fue portar servicios, beans y configuración de Spring al nuevo Tapestry5 IoC. Una de las principales diferencias entre los dos contenedores es que la inyección de dependencias en Tapestry5 se realiza por contructor en lugar de por setters. Esta fue la principal razón que impidió que el port de un IoC a otro fuera completamente automático.

Mientras reescribía los constructores noté que muchos de los servicios tenían variables de instancia con referencias a otros servicios que ahora ya no era necesario mantener como variable de instancia. Saltó la alarma:

POSIBLE MEMORY LEAK!!!! POSIBLE MEMORY LEAK!!! POSIBLE MEMORY LEAK!!!!.

Estas variables de instancia tranquilamente podían convertirse a variables internas de métodos (constructores) o simplemente eliminarse. Como consecuencia de esta reducción en variables de instancia se reduce considerablemente la cuenta total de referencias de instancias de varios de los servicios. Llegando en varias ocasiones a tener servicios procesados por el GC y eliminados completamente de la memoria.

La conclusión final es que muchos de los servicios de Spring configurados con "init-method" o que utilizan afterPropertiesSet(), o algún mecanismo similar, terminan conteniendo referencias a servicios que solo son necesarios durante bootstrap y por ende aumentando la cuenta de referencias de esos objetos que no son necesarios para continuar con la ejecución de la aplicación.

Soy consiente de que en un entorno clásico de IoC (Tapestry, Spring o cualquiera), los males provenientes pura y exclusivamente de mantener estos objetos en memoria son despreciables y que seguramente se podría lograr una reducción similar en Spring rediseñando los servicios. Pero este post no se trata de eso, este post es simplemente una reflexión sobre lo que damos por sentado los Java adictos GC dependientes como yo.

ZTT y Tapestry5

Al comenzar a hablar de ZTT en java hay que hacer la siguiente aclaración: es prácticamente imposible asegurar que cualquier estrategia para ZTT para java funcionará en el 100% de los casos.
La principal razón para esto es que no hay una manera estándar establecida de hacer manipulación de bytecode de clases (weaving), y entonces cada framework o librería implementa su manera: algunos usan AspectJ, otros Javassist, otros Jakarta Commons JCI y otros como Tapestry5 implementan su propio ClassLoader.
Esto lleva a que varios esfuerzos para aproximarse a ZTT resulten incompatibles entre si y con determinados frameworks. El caso más típico es Hibernate. En esta serie de post veremos diferentes estrategias para acelerar el desarrollo al utilizar frameworks como Trails, Tapestry4, Tapestry5, Spring. Pero cuando se trata de Hibernate siempre hay que hacer consideraciones aparte, porque al realizar una modificación sobre una clase del modelo Hibernate, no todas las estrategias para ZTT funcionan correctamente. Hibernate tiene su propio weaving de classes (weaving estático con Javassist) que no permite hacer el cambio "on the fly" de una clase sin notificarle a Hibernate y recargar toda la configuración. En otro post mostraré de que manera se puede disminuir el impacto de esta limitación de Hibernate recargando el contexto de Spring.

Tapestry5 seamless ZTT


Una de las nuevas características de Tapesty5 es la recarga automática ("on the fly") de clases o templates que hayan sido modificados (Live Class and Template Reloading).
Lo mejor de la implementación de Tapestry5 es que funciona exactamente igual en desarrollo que en producción y no necesita (prácticamente) ninguna configuración o consideración extra.
Para verlo en funcionamiento se pueden consultar los excelentes screencasts de Tapestry5 que Howard ha preparado como introducción a las diferentes características del framework.
Incluso es realmente fácil de probar para aquellos familiarizados con Maven. Existe un archetype que permite probar estás caracteristicas de Tapesty5 en 10 minutos.
Las limitaciones: Tapestry5 implementa su propio ClassLoader y debido a la ambigüedades en las especificaciones de "class loading" (lo que ha generado varias discuciones) para servidores de aplicaciones, hay que tener ciertas precauciones al usar otros servidores de aplicaciones que no sean Jetty.
Otra limitación es que el class reloading se limita a clases controladas por Tapestry5 IoC, por lo que si el cambio ha sido en clases del modelo Hibernate o alguna clase que se inyecta via Spring, estos cambios no serán detectados.

Tapestry5 "Live Class and Template Reloading" es LO MEJOR (dentro del open source) que he visto para facilitar la vida del desarrollador web java y reducir el tiempo del ciclo de deployment al mínimo posible. Gracias a esta característica creo se convertirá en "él" framework web java del 2008 y seguramente volverá a ganar el premio que otorga Sun a la innovación en Java.