¡¡¡Juira, Pico!!!

En el post anterior contaba que había reemplazado Picocontainer en mi aplicación con Spring (de paso lean este post que me causó bastante gracia por lo oportuno).

La verdad es que esperé demasiado para volar a Pico, debería haberlo hecho antes. Pero creo que arrugué porque es un cambio grande, y estaba teniendo demasiada carga de trabajo como para dedicar tiempo en algo que no iba a resultar visible, ya que desde el punto de vista del usuario, nada cambia.
Lo que finalmente me llevó a decidir el cambio, fue lo siguiente: necesitaba usar Quartz Scheduler para programar la generación automática de unos reportes. Como debia quedar programado continuamente, necesitaba que los jobs del scheduler fueran persistentes. Quartz ofrece un jobstore que usa JDBC, pero el problema es que usa su propia conexión a la BD, con su propio pool de conexiones, en este caso DBCP, mientras que yo vengo usando c3p0 desde hace tiempo (ya que Hibernate 3 no soporta más DBCP). Entonces, si lo hubiera usado de esa manera, me hubiera quedado la aplicación con dos connection pools independientes, y encima diferentes. Inaceptable.
Habia dos soluciones: escribir mi propia implementación de JobStore, o aprovechar que Spring ya lo hizo. Y como si hay algo que no me gusta es reinventar la rueda, pues… 

 

Como cualquier tarea complicada, es mejor separarla en partes mas manejables. Entonces, mi primer objetivo fue reemplazar a Pico solamente en la función de Dependency Injection, dejando para más adelante otras integraciones que ofrece Spring. Sin embargo, debido a que Pico estaba integrado con Struts, proveyendo DI a las actions de Struts, de alguna manera tenia que usar la integración de Spring con Struts. Para eso tenía dos opciones:

Usar ContextLoaderPlugin, un plugin de Struts que hace que los actions se manejen como beans de Spring, y que las dependencias se inyecten automáticamente, pero que tiene la enorme desventaja de tener que duplicar la definición de beans: además de definir las actions en struts-config.xml, tambien lo tengo que hacer en action-servlet.xml, para definirles las dependencias. Encima, yo usé wildcards en la definición de las actions para hacer mas chico el archivo, y esto no esta soportado de ninguna manera, lo que implicaría además, reescribir el struts-config.xml para quitar los wildcards. Ni en pedo. Antes dije que la integración de Pico con Struts era un poco mejor que la de Spring, y es justamente por esto, con agregar un servlet filter, Pico inyecta las dependencias directamente en las actions usando autowire, no hay que hacer más nada.

Usar ActionSupport, una clase de la que hay que hacer heredar todas las actions. Esta clase provée un método para obtener el application context, y de ahí los beans necesarios, pero el caso es que al final, la inyección de dependencias la tengo que terminar haciendo yo… tampoco me convence.

Sin embargo, la clave estaba en este última clase, ActionSupport. Si ActionSupport sabe como obtener un appicationContext, debería haber alguna manera de inyectar las dependencias automáticamente, usando autowiring.
En el libro de Rod Johnson, muestran una manera de hacerlo:

 

public class AutowiringActionSupport extends ActionSupport {

  protected void onInit() {
    getWebApplicationContext().getBeanFactory().autowireByType(this,
      AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, true);
  }
}

ActionSupport tiene un método onInit() que se llama desde el constructor. Por lo tanto, si todas las action heredan de esta clase, cada vez que se instancie una de ellas, se ejecuta este código y se inyectan las dependecias. Perfecto, justo lo que necesitaba!. Sin embargo, se vé que este código fue escrito hace mucho, ya que no funciona en Spring 1.2.8 ni en 2.x . El método getBeanFactory() no existe (fue reemplazado por getAutowireCapableBeanFactory()), y autowireByType() tampoco, fue reemplazado por dos métodos, autowire() y autowireBeanProperties(). El primero no me sirve porque devuelve una nueva instancia del bean (y recuerden que yo estoy dentro del bean), y el segundo no permite hacer autowire por tipo, menos aún inyección en el constructor (ya que el bean ya esta instanciado). Pero lo que sí se puede hacer es esto:

 

protected void onInit() {
    getWebApplicationContext().getAutowireCapableBeanFactory().
        autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, false);
}

Esto significa que estoy inyectando las dependencias en el objeto actual, que las voy a inyectar según el nombre (Spring busca properties en el bean que tengan el mismo nombre que el bean id), y el false del final significa que no voy a verificar si queda alguna alguna propiedad del bean sin setear.

En síntesis, para que esto funcione, tuve que hacer los siguientes pasos:

• Hacer que mi action padre herede de ActionSupport.
• Sobreescribir el método onInit() en mi clase padre.
• Cambiar el nombre de algunas properties de las actions, para que coincidan exáctamente con los id de los beans.
• Agregar los setters que me faltaban (recuerden que antes usaba exclusivamente constructor injection).

Esto fue relativamente fácil gracias a las opciones de refactoring y creación de código de Eclipse.
El resto fue simplemente terminar de armar el applicationContext.xml como para cualquier aplicación Spring, para lo que simplemente modifiqué los archivos xml de Pico.

Ahora ya tengo la aplicación con Spring en producción y andando sin problemas, algo de lo que estoy muy contento. El próximo paso será  aprovechar las integración con Hibernate, para lo que pienso implementar un DAO genérico, como se explica en este artículo.

| show comment » | « hide comment 1 Comment so far
Leave a comment



Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Name (required)

E-mail (required)

URI

Your Comment