Struts

Realmente son dos frameworks que por el nombre parecen bastante similares, sin embargo hay que decir que existen actualmente muchas diferencias entre ellos. La comparativa oficial está en la página web de apache http://struts.apache.org/2.1.6/docs/comparing-struts-1-and-2.html, sin embargo intentaremos comentarlas un poco para que queden lo suficientemente claro:

Clases Action

Struts1
Se Requiere extender de la una clase Action abstracta, el problema común en Struts1 reside en que se programan clases abstractas en lugar de interfaces.

- Recordamos que los interfaces no se extienden si no que se implementan y las clases abstractas por el contrario sí.
- Las clases abstractas pueden tener métodos concretos y otros abstractos, sin embargo los interfaces solo pueden contener métodos abstractos.


Struts2
Un Action puede implementar una interfaz Action, además de otras interfaces que le permitan integrar mas servicios. Struts2 provee de una clase base ActionSupport que implementa las interfaces comúnmente usadas. Además esta interfaz no es requerida. Cualquier POJO con un método de ejecución puede ser usado como Action en Struts2. 

Modelo de hilos

Struts1
Las Actions implementan el patrón singleton y deben ser thread-safe por lo que puede haber solo una instancia de una clase para manejar todas las peticiones para ese Action. La estrategia singleton pone restricciones sobre lo que podemos hacer con los Actions de Struts1 y se requiere un cuidado extra para desarrollar, a demás, Los recursos usados para los Actions deben ser thread-safe o sincronized. 

- Recordamos que Singleton es un patrón de diseño muy utilizado cuyo objetivo es mantener la instancia de un objeto a lo largo de la ejecución de la aplicación, es decir que asegura una única instancia de un objeto. No es muy bueno abusar de Singleton, es mejor la gestión de Hilos de ejecución o Threads para el tema de la seguridad.

Struts2
Los objetos Action son instanciados por cada petición, por lo que no hay problemas de tipo con la seguridad de hilos. En la práctica, los contenedores de servlets generan muchas instancias, así que un objeto mas no representa problemas de rendimiento y de impacto en el garbage collection.

Dependencia de los Servlets

Struts1
Las Actions tiene dependencias de la API de Servlets dado que HttpServletRequest y HttpServletResponse son pasados al método excecute cuando la Action es invocada.

Struts2
Las Actions no están acopladas al contenedor. A menudo el contexto de los servlets esta representado por simples Maps, permitiendo a las Actions ser probadas de forma aislada. Las Actions de Struts2 puede mantener el uso del request y el response si se requiere. De cualquier forma, otros elementos de la arquitectura reducen o eliminan la necesidad de acceder a HttpServetRequest o a HttpServletResponse directamente.

Manejo de pruebas

Struts1
El principal obstáculo para las Actions de Struts1 es que la ejecución de métodos requiere de la API de Servlets. Una extensión de terceras partes, como Struts TestCase, que ofrece un conjunto de simuladores para objetos de Struts1.

Struts2
Las Actions pueden ser probadas instanciado la Action, estableciendo propiedades e invocando métodos. El soporte a la Inyección de Dependecias permite hacer las pruebas de forma simple.

Recolección de datos de entrada

Struts1
Es necesario el uso de un objeto ActionForm para capturar las entradas. Como las Actions, todos los ActionForm deben extender de una clase. Como algunos JavaBeans no implementan de ActionForm los desarrolladores a menudo crean clases redundantes para capturar a las entradas. Los DynaBeans pueden ser usados de forma alternativa para crear clases ActionForm convencionales, pero, los desarrolladores deben JavaBeans existentes.

Struts2
Usa las propiedades de las Actions para manejar las entradas, elimina la necesidad de un segundo objeto de entrada. las propiedades de entrada pueden ser objetos de una amplia variedad que incluso pueden tener sus propias variables. Las propiedades de las Action pueden usadas por la pagina Web por medio de los TagLibs. Struts2 soporta incluso el patrón de ActionForm, asi como objetos y acciones POJO. Tipos de objetos, incluyendo negocios o objetos de dominio, pueden ser usados como objetos en entrada y salida. La característica ModelDriven simplifica las referencias por taglib a objetos POJO.

Lenguaje de Expresiones

Struts1
Esta integrado con JSTL, así que usa el JSTL EL. El EL tiene una traza grafica de objetos básica y una relativamente pobre colección e indexación de soporte a propiedades.


Struts2
Puede usarse JSTL, pero el marco de trabajo soporta ademas un lenguaje de expresiones mas poderoso y flexible llamado "Object Graph Notation Language" (OGNL)

Vinculación de objetos de la vista

Struts1
Usa el mecanismo estándar de JSPS para el vincular objetos en el contexto de las páginas.

Struts2
Usa una tecnología llamada "ValueStack" donde los taglibs pueden acceder a valores sin estar acoplados a la vista donde el tipo de objeto se renderea. La estrategia del "ValueStack" permite reutilizar vistas gracias al rango de variables que pueden tener el mismo nombre pero tipo diferente tipos de propiedades.

Conversion de tipo

Struts1
Las propiedades de los ActionForm son usualmente Strings. Struts1 usa comúnmente Commons-Beanutils para la conversión de tipos. Las conversiones son configurables por clase y no por instancia.

Struts2
Usa OGNL para la conversión de tipos. El marco de trabajo incluye convertidores para objetos básicos y tipos primitivos.

Validación

Struts1
Soporta validación manual por medio de métodos en el ActionForm, o a través de una extensión de los Commons Validator. Las clases pueden tener diferentes contextos de validación para la misma clase, pero no pueden encadenar validaciones en sub objetos.

Struts2
Soporta validación manual por medio de métodos y por el marco de trabajo XWork Validation. El XWork soporta encadenamiento de validaciones en las subpropiedades usando las validaciones definidas para las propiedades de la clase y el contexto de validación.

Control de la ejecución del Action

Struts1
Soporta Request Porcessors (Ciclos de vida) separados por cada módulo, pero todas las Actions en el módulo deben compartir el mismo ciclo de vida.


Struts2
Soporta ciclos de vida diferentes, uno por Action por medio de la pila de interceptores. Pilas configurables pueden ser creadas y usadas con diferentes Actions si es necesario.

Fichero de configuración


Struts1
El fichero de configuración de struts se llama struts-config.xml.


Struts2 
En este caso se llama struts.xml.