Finalmente, algo en contra de las redes sociales / Finally, something against social networks.

Powered by ScribeFire.

Integrando Maven2 y Eclipse WTP / WTP and Maven2 integration

Powered by ScribeFire.

Agile no es un falso dilema.

Qué pasa con .net?

Mi aplicación necesita bajar información casi en tiempo real de otras aplicaciones de otras empresas. Por el momento, se conecta con 5 otras aplicaciones.

El proceso no es exáctamente igual con cada aplicación, pero es similar, básicamente cada tantos segundos les pido que me manden un documento XML con nuevos datos. Esto lo hacemos con un simple POST sobre HTTP (con SSL para que viaje todo encriptado). Las otras empresas usan tecnologías diversas. Dos usan Java, una usa PHP y dos más usan .net

Ahora, lo extraño es que la mayor cantidad de problemas los tenemos con aquellas empresas que usan .net.

Con la primera de ellas, una empresa de UK con la que empezamos a trabajar hace ya algunos meses, cada tanto teníamos problemas de timeouts, que finalmente terminamos resolviendo usando HTTP/1.0 en lugar de HTTP/1.1. También tuvieron problemas con las fechas y horas cuando se terminó el horario de verano y se atrasó una hora.

Con la segunda, una empresa de USA estamos terminando la implementación ahora mismo. Todavía no puedo asegurar que funcione bien, despues de algunas horas de funcionamiento, su servidor se empieza a tomar demasiado tiempo en responder (hasta 60 segundos en algunos casos). Anoche simplemente dejó de responder de un instante a otro.
También, les tuve que pedir que me manden la fecha en UTC o al menos incluyendo el timezone, ya que ellos mandaban alegremente la hora local y sin timezone, por lo tanto yo no tenía una referencia para poder convertir esa hora a otra. Y el gran problema hubiera aparecido cuando comience el horario de verano. Todo esto me pareció extraño viniendo de personas que viven en un país con 5 zonas horarias distintas y con horario de verano.

Soy 99.99% ignorante sobre .net y todas las tecnologías de Microsoft (la última vez que hice algo con Microsoft debe haber sido en 1995 cuando hice una aplicación de IVR en VB 5, que si bien tenia funcionalidades muy interesantes, no estoy particularmente orgulloso de como fue hecha  internamente), pero esto me lleva a preguntarme… tiene .net el mismo problema que tantas otras aplicaciones Microsoft, que funcionan bien la mayor parte del tiempo, pero en algún momento fallan? O es un problema de la gente que trabaja con Microsoft? Hay alguna relación entre el uso de .net y la calidad de sus desarrolladores? Quizá son ex desarrolladores VB?

Update: creo que en realidad hay algún problema con la implementación del protocolo HTTP en .net, específicamente en el manejo de 100 Continue, no sería la primera vez que una implementación de Microsoft no cumple 100% con el standard.  Los problemas de ambas aplicaciones con .net estan relacionados con esto. Igualmente, les tuve que indicar donde estaba el problema.

Si, soy haragán.

A consecuencia de haber leido este post, me puse a pensar que fue lo último que hice tratando de buscar la mejor solución, y no la que hubiera usado sino me ponía a investigar 5 minutos.

Y encontré este simple caso:

Como decía en un post anterior, estuve haciendo un programador (scheduler) de reportes. El requerimiento era que fuera flexible y fácil de usar, ya que los mismos usuarios finales lo van a utilizar para programar los reportes. Para el caso de la periodicidad, obviamente no podia simplemente poner un campo donde ingresar una expresión Cron, porque entonces nadia iba a ser capáz de usarlo. Se me ocurrió entonces poner una serie de opciones, que el usuario podía elegir: Una vez, Diario, Semanal, Quincenal, Mensual, etc.  

Para la parte de interface del usuario, ya habia decidido usar Stripes para todo lo nuevo (e ir lentamente migrando lo antiguo de Struts). Stripes se basa fuertemente en Java 5, y por lo tanto trae algo muy interesante que es un tag de JSP stripes:enumName() , que sirve para mostrar los valores de una enumeración. Esto está buenísimo, porque me hago un loop y muestro todos los valores de un Enum como radio buttons: 

<c:forEach var=”freq” items=”<%= ReportFrequency.values() %>”>
    <s:radio value=”${s:enumName(freq)}” name=”definition.frequency” id=”definition.frequency.${s:enumName(freq)}”     class=”radio”/>
    <s:label for=”definition.frequency.${s:enumName(freq)}”>${s:enumName(freq)}</s:label>
</c:forEach> 

Lo mejor de todo esto, es que cuano el valor llega a mi Action de Stripes, me llega como un Enum del tipo ReportFrecuency (gracias al maravilloso binding de Stripes). El detalle acá, es que los Enum de Java 5 no son simples constantes, sino que también pueden tener comportamiento.
Mi Enum ReportFrecuency esta definido asi: 

public enum ReportFrequency {
    Once(TriggerUtils.makeImmediateTrigger(0, 0)),
    Hourly(TriggerUtils.makeHourlyTrigger()),
    Daily(TriggerUtils.makeHourlyTrigger(24)),
    //etc

    private Trigger trigger;

    ReportFrequency(Trigger trigger) {
        this.trigger = trigger;
    }

    public Trigger getTrigger() {
        return trigger;
    }
}

O sea que luego, lo único que tengo que hacer cuando creo el Trigger para el Scheduler, es: 

Trigger trigger = definition.getFrequency().getTrigger();

Facilícimo. Y agregar una nueva frecuencia solo implica agregar un nuevo valor al Enum, no hay que tocar absolutamente nada más!.

Ahora, cómo hubiera hecho sino hubiera usado Enums y Stripes? Lo mas asqueroso que se me ocurre es todo hardcodeado, con los valores en strings repetidos en la vista y en el action, y una serie de ifs para elegi el Trigger. Algo un poco mejor podría haber sido usar constantes  static final String (pero igualmente hubiera tenido que escribir cada radiobutton individualmente), y después haber usado algún factory para obtener el Trigger correspondiente.

Creo yo que esta es la mejor solución posible (por lo menos a mi no se me ocurrió nada mejor), y además es extremádamente fácil de mantener. Las otras soluciones implican escribir mas, y son difíciles de mantener, porque hay que cambiar varias cosas en varios lados, y mantener esos cambios sincronizados. Es cierto, quizá haya tardado un poco más en implementar esta solución porque tuve que investigar un poco sobre Enums y Stripes, pero el resultado es mucho mas robusto, agregar alguna frecuencia en el futuro es una pavada, y además aprendí algo nuevo.

Y la satisfacción de haber hecho las cosas bien, es impagable.

¡¡¡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.

Pico vs. Spring

Hace mucho que quería escribir esto, pero por una razón u otra lo fui posponiendo, pero ahora que finalmente reemplacé Pico por Spring en la aplicación, creo que es un buen momento.

El proyecto en el que vengo trabajando hace mas de un año, usaba originalmente Picocontainer como container de dependency injection (DI). La razón, sin entrar mucho en detalles, fue que la persona que actuaba como arquitecto en ese momento, es uno de los commiters del proyecto Pico, y por lo tanto lo impuso a pesar que el resto del equipo se inclinaba por Spring, con el que ya teníamos experiencia previa (como comentario al margen, tampoco nos dejó usar Java 5…).

En primer lugar, aclaremos que Pico cumple su cometido impecablemente. Provee DI a una aplicación web sin problemas,  provee  constructor  injection o  setter injection (aunque esta última vaya uno a saber como se hace). Para  poder externalizar  la configuración a un XML externo, o bien a un script Groovy o Jyton, hay que usar Nanocontainer, otro paquete de los mismos autores.  Hasta aquí todo muy bien, pero la pregunta es, por qué un proyecto debería usar Pico en lugar de Spring? Qué tiene mejor Pico que Spring, o que ofrece Pico que no pueda ofrecer Spring?

Veamos un poco en detalle:

Pico es muy “liviano”.

Es cierto, el tamaño de los .jar de Pico + Nano + Nanowar apenas pasa los 300Kb, mientras que el paquete completo de Spring son mas de 2Mb. Sin embargo, Spring también se distribuye en varios .jar separados y uno puede elegir deployar solo lo que uno va a usar. Pero en el peor de los casos, cuál es el problema para una aplicación que corre siempre en un mismo server? Quizá el deployment que hago una vez por semana tarde 20 seg. mas.

Pico provee constructor injection.
Si bien la gente de Spring promueve setter injection, a diferencia de la de Pico que promueve constructor injection (no me voy a explayar en esto, cada uno tiene sus méritos), no significa que que Spring no soporte constructor injection. De hecho, lo soporta mejor que Pico, paso a explicar:
Por default, Pico trabaja con autowire, lo que significa que automágicamente descubre que beans tiene que inyectar según el tipo de los beans y los tipos definidos en el constructor. Pico enfatiza mucho este aspecto, porque según ellos ayuda a mantener el XML de configuración en un tamaño reducido. Por ejemplo, si tenemos la siguiente clase:

package com.sarcobjects.persistence.hibernate;

public class HibernateGamePersister     extends HibernatePersisterSupport     implements GamePersister, Serializable {

    public HibernateGamePersister(SessionFactory factory) {
        super(factory);
    }
    …
}

El constructor necesita una instancia de la clase SessionFactory. Entonces, este fragmento de XML es suficiente para configurarlo:

<component-implementation class=’com.sarcobjects.persistence.hibernate.SessionFactory’ />
<component-implementation class=’com.sarcobjects.persistence.hibernate.HibernateGamePersister’/>

Pico descubre que el tipo que necesita inyectar es SessionFactory, lo busca en el XML y si lo encuentra lo inyecta.
El equivalente en Spring sería:

<bean id=”gamePersister” class=’com.sarcobjects.persistence.hibernate.HibernateGamePersister’ autowire=”constructor”/>

La diferencia es que le tengo que agregar autowire=”constructor” porque para Spring el default es setter injection.
Hasta acá todo muy lindo, pero el problema aparece cuando le tengo que pasar además, por ejemplo,  una constante, o bien el archivo de configuración contiene mas de una definición del mismo tipo.  Ahí ya pierdo todo lo automágico y no me queda mas remedio que explícitamente definir que quiero inyectar. Por ejemplo:

<component-implementation class=”com.sarcobjects.web.admin.dashboard.QuartzDashboardScheduler”>
    <parameter key=”service” />
    <parameter key=”factory” />
    <parameter key=”gameStatus” />
    <parameter>
        <int>10</int>
    </parameter>
</component-implementation>

Aquí necesito pasarle un valor directamente desde la configuración, pero si le paso solamente el parámetro int, Pico no sabe de donde sacar los otros parámetros, y por lo tanto tengo que definirlos explícitamente. La misma configuración en Spring sería:

<bean class=”com.sarcobjects.web.admin.dashboard.QuartzDashboardScheduler”     autowire=”constructor”>
    <constructor-arg index=”3″ value=”6″ />
</bean>

Sólo tengo que incluir el parámetro que Spring no puede deducir. No es que Spring sea mas inteligente, pero la configuración nos permite mezclar parámetros implícitos con explícitos, con el objeto de mantener el tamaño del XML al mínimo. 

Pico soporta diferentes scopes para los beans: application, session y request.
Esto era cierto hace un año, pero ahora Spring 2 también soporta session y request, además del clásico application. Sin embargo, en esta aplicación jamás usamos otros scope que no fuera application.

Pico se integra con Struts y WebWorks, con Hibernate y tiene soporte para AOP.
La integración con Struts esta bien, hasta quizá sea levemente superior a la de Spring. La integración con Hibernate no pasa de soportar un SessionFactory, y la de AOP no tengo idea, quiza si hubiera documentación…
Spring obviamente se integra con estos y muchos mas Frameworks, y de una manera mucho mas completa.

En síntesis, Spring puede hacer todo lo que Pico hace. Sin embargo, si hacemos la pregunta al revés, puede hacer Pico todo lo que Spring hace?
Definitivamente, no. Para empezar, la documentación. Nosotros usamos Pico en un nivel aceptable porque teníamos a uno de los autores en el equipo. Pero no veo cómo alguien que quiera usar Pico pueda sacarlo andando razonablemente con la documentación que se ofrece en el sitio. En contraposición, Spring tiene una muy buena documentación, varios libros, y miles de desarrolladores en todo el mundo que nos pueden ayudar.
No voy a enumerar todas las facilidades que además aporta Spring (se pueden encontrar por toda la web) para desarrollar una aplicación, pero por ejemplo, el soporte para demarcación declarativa de transacciones me parece buenísimo. De hecho, la arquitectura impuesta por este arquitecto no permite tener transacciones que abarquen mas de una tabla! O sea que básicamente nuestra aplicación no es transaccional.

En fin, cuándo se debería usar Pico? Quizá en aplicaciones chicas, puntuales, que no necesiten integrarse con demasiados otros frameworks, que necesite ser distribuida a muchos puntos.
Pero en aplicaciones mediana a grandes, transaccionales, con integración a otros frameworks, con acceso a web services, y que pueda escalar., no me cabe duda que Spring es una solución muy recomedable.

En el próximo post voy a contar lo que tuve que hacer para volar Pico e  instalar Spring en la aplicación.

Update 26/11: Olvidé comentar que el SpringIDE para Eclipse, facilita todo aún mas al manejar los archivos .xml de Spring, con el autocompletado de elementos, y nombres de clases. Permite clickear en un bean y abrir la clase respectiva en el editor. Nos avisa si hay una referencia a un bean que no existe, o si falta algun setter o constructor para poder inyectar todas las dependencias. Y como si esto fuera poco, además nos genera un gráfico con el mapa de los beans, aunque claro, esto solo funciona cuando las dependencias estan marcadas explícitamente, y no con autowire (aunque podría, supongo que una próxima versión lo incluira).

100% Test Coverage

Leí esto y recordé que quería escribir un poco sobre este tema.
Hay gente que le da mas importancia al test coverage que a los tests en si.
Te dicen, el coverage tiene que estar al 100% (o al 90% o al procentaje que sea). La cuestión es que de esa forma, uno termina perdiendo el tiempo escribiendo tests para código trivial, como por ejemplo los getters y los setters. Esto es peligroso, porque el desarrollador lazy (y todos somos algo lazy), va a empezar a hacer trampa. Es perfectamente posible (y facil) escribir tests "dummy", que en realidad no hagan nada, pero recorran el código. Eso hace que el test coverage salga fenómeno, todos felices, pero en realidad los tests no sirven para nada.

Que yo sepa no existe una herramienta que de alguna manera indique la calidad de los tests, creo que eso seria bastante mas útil que el test coverage. Con esto no quiere decir que el test coverage no tiene su utilidad, porque puede haber casos donde nos pasemos por alto alguna parte donde los test sean importantes, y el test coverage nos avisa, y por eso tiene que estar en el proceso de building.

Concretamente, a lo que voy es que no tiene mucho sentido decir "la aplicación tiene un 100% de test coverage", porque eso realmente no me dice nada, ni me asegura que la calidad del producto sea alta.

Excepciones en Hibernate 3.x

Una de las cosas que se criticaba de Hibernate 2 era que sus excepciones (HibernateException para ser específico) eran checked, y por lo tanto no habia mas remedio que catchearlas en todos los métodos que las tiraran, o bien tirarlas explícitamente. Spring presentó una solución a esta situación, ya que si uno usaba el HibernateTemplate provisto con Spring, HibernateException era reemplazada excepciones unchecked, y por lo tanto no era necesario catchearlas en todos lados. Mas aún, HibernateException era reemplazada por toda una jerarquía de excepciones, que permitian tener un conocimiento mas acertado del error ocurrido en la base de datos. Encima de todo, esta jerarquía era la misma para cualquier BD, y para cualquier método de acceso a BD soportado por Spring, ya sea Hibernate, JDBC, JDO, iBatis o TopLink. Asi teníamos por ejemplo DataIntegrityViolationException (cuando intentamos insertar o updatear un registro que viola alguna constraint), BadSqlGrammarException (cuando tratamos de ejecutar algún SQL inválido), etc.

Esto a mi entender tenia dos beneficios: por un lado, no es necesario catchear ni tirar las excepciones en la capa de acesso a datos, se puede hacer en una capa mas alta, y por otro, puedo tener una idea mas acertada de lo que realmente pasó en la BD, todo esto independientemente de la BD o el mecanismo de acceso a la misma que este usando, y sin crear una dependencia a ésta.

Con Hibernate 3, la cosa cambió un poco.  Si bien es perfectamente posible seguir usando el HibernateTemplate de la misma manera, Hibernate 3 ofrece por sí mismo algunas cosas mas.

Para empezar, HibernateException es ahora unchecked y por lo tanto ya no es necesario catcharla en la capa de acceso a datos. Esto que a priori puede parecer una gran ventaja, quizá no lo sea tanto, ya que si dejamos que HibernateException suba por todas las capas y la catcheamos quizá cerca de la vista, estamos introduciendo una dependencia con Hibernate en todas las capas. Puede que esto no nos importe en algún caso, pero si queremos que nuestra aplicación tenga todas sus capas bien diferenciadas e independientes como para que en el futuro podamos reemplazar alguna sin mayores problemas, esto es incorrecto.

Por otro lado, Hibernate 3 agregó también una jerarquía de excepciones que dependen de HibernateException. Tenemos por ejemplo, ConstraintViolationException (cuando intentamos insertar o updatear un registro que viola alguna constraint), JDBCConnectionException (si perdimos la conexión a la BD), etc

De esta manera, es posible manejar las excepciones de una manera similar a Spring.  Otra novedad de Hibernate 3, pero que escapa un poco al alcance de este artículo, es SessionFactory.getCurrentSession(), que permite mantener una session abierta a lo largo de la aplicación y usarla cuando la necesitemos, sin necesidad de abrirla y cerrarla manualmente cada vez.

Todo esto implica que con Hibernate 3 es posible tener nuestros DAOs como simples POJOs, sin necesariemente tener que usar Spring. Por supuesto que todavia estamos dejamos de lado algunas ventajas, como por ejemplo manejo de transacciones en forma declarativa, pero es una alternativa.

Por ejemplo, en mi proyecto actual no usamos Spring (no porque yo no quiera ni porque no lo considere bueno, sino por otras razones que ya comentaré en otro post), y dentro de mis Hibernate DAOs, el approach que use para manejar las excepciones es algo así:

public void saveCustomers(Customer[] customers) throws PersistenceException {
        String msg = null;

        try {
            msg = getCustomerNames();
            saveOrUpdate(openSession(), customers);
        } catch (ConstraintViolationException cve) {
            throw new PersistenceException("persister.customer.save.constraint.exception", new Object[] {msg, cve.getConstraintName()}, cve);
        } catch (HibernateException e) {
            throw new PersistenceException("persister.customer.save.failed", new Object[] {msg}, e);
        }
    }

Yo particularmente prefiero que las excepciones de Hibernate no salgan de la implementación de los DAOs y por lo tanto, las reemplazo con PersistenceException (que forma parte de una jerarquia de excepciones propia de mi aplicación), pero les pongo el mensaje que yo quiero, de manera de informarle el error al usuario de la manera mas amigable y acertada posible. Noten que ConstraintViolationException provee un método getConstraintName(), que devuelve el nombre de la constraint violada. Si en la base de datos uno se toma el trabajo de ponerle nombres lo suficientemente descriptivos a las constraint, el usuario va a terminar viendo una descripción bastante correcta de cual fue el problema, y hasta quizá pueda resolverlo por si mismo, o en el peor de los casos un administrador no va a tener que andar buscando en enormes logs cual fue el problema para poder resolverlo. 

En una capa superior de mi aplicación:

    private String saveCustomer(StrutsCustomerForm form) {
        Customer customer = null;
        try {
            validateCustomerForm(form);
            customer = toCustomer(form);
            customerDAO.saveCustomers(new Customer[] {customer});       
        } catch (Exception e) {
            addMessageException(e);
            saveMessages();
            return ERROR;
        }
        return SUCCESS;
    }

Aquí simplemente cacheo Exception, porque sé que todas las otras capas de mi aplicación ya reemplazaron las excepciones respectivas por alguna de mi jerarquia propia y le pusieron un mensaje (que dicho sea de paso, es un key de un resource bundle, ya que mi jerarquia de excepciones sobreescribe getLocalizedMessage() para soportar i18n), que es lo que termina en la pantalla del usuario.

JSTL y EL en Tomcat 5.x

Este es un problema que aparentemente le ocurre a bastante gente, incluyéndome.

La mayoría de los artículos sobre JSTL dicen que hay que poner el siguiente tag para poder usar los tags de JSTL con expresiones EL:

< %@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>

Pero al escribir en el JSP algo asi como:

<c:if test="${param.isPopup}" >

nos encontramos conque el JSP no se muestra, y aparece una linda excepción:

According to TLD or attribute directive in tag file, attribute test does not accept any expressions

Lo qué? No era que se podian usar las expresiones EL? Con esto uno se puede romper la cabeza varias horas, hasta que en algún lugar alguien sugiere usar:

< %@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c"%>

Entonces todo funciona bien, pero cómo puede ser si ese uri es para run time expressions, las antiguas y limitadas expresiones de JSP?

La respuesta a esto yace en Tomcat. La version 5.x soporta JSP 2.0, que incluye soporte para expresiones EL. Entonces, al usar la version EL de los tags JSTL, las expresiones se intentan evaluar dos veces: una por Tomcat, y otra por los tags. La versión RT no intenta evaluar la expresión EL que ya evaluó Tomcat, y por lo tanto funciona.

La solución correcta? Usar el uri de la versión 1.1 de JSTL, que es este:

< %@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>

Corolario:

No olvidemos que como Tomcat evalúa las expresiones EL directamente, éstas se pueden escribir en el código HTML sin necesidad de usar el tag <c:out>, por ejemplo:

<h1>${form.pageTitle}</h1>