Framework Struts2

Pablo Cáceres F.

Introducción Struts 2 es un framework de presentación, basado en el

patron MVC. Se distingue su amplia capacidad de configuración y

extensibilidad. Permite el uso de plugins de componentes e integracion con otros frameworks.

Arquitectura – Patrón MVC

Principales componentes Los principles componentes de framework son:

DispatcherFilter Interceptors Actions Results

DispatcherFilter Es el punto de entrada del framework. A partir de el se lanza la ejecución

del procesamiento para cada request que involucre al framework. Sus principales responsabilidades son:

Ejecutar los Actions (handlers para los request) Comenzar la ejecución de la cadena de interceptors (interceptors chain)

asociados al request Limpiar el ActionContext? (para evitar memory leaks). El ActionContext? es el

contexto sobre el cual se ejecuta un Action.

Principales componentes Interceptors

Son clases que siguen el patrón interceptor. Se encargan de interceptar la invocación a un Action. Permiten realizar operaciones antes y después de la invocación de un Action. También permiten evitar que un Action se ejecute. Nos sirve para reutilizar cierta funcionalidad que queremos aplicar a un conjunto de Actions.

Struts2 trae definidos un conjunto de interceptors por defecto, que le permite realizar un conjunto de acciones sobre los Actions, el Request y Response. Estas acciones son, por ejemplo: validaciones de los parámetros de entrada, inyección de dependencia, logueo, etc.

Principales Componentes Actions

Los Actions serán lo encargados de ejecutar la logica necesaria para manejar un request determinado. A diferencia de versiones anteriores de struts, los Actions no estan obligados a implementar o heredar de una interfaz o clase ya definida. Pueden ser POJOs. Igualmente, struts2 posee una interfaz Action. Esta interfaz permite definir el método por defecto que se ejecutará sobre el Action para que no tengamos que definirlo por otro medio (Existen varias formas de indicarle a Struts2 el método a invocar sobre un action). También existe una implementación de esta interfaz, denominada ActionSupport, que nos provee funcionalidad de gran utilidad necesaria por un conjunto de Interceptors para poder manipular el Action a invocar.

Principales Componentes Results

Los Results son Objetos que encapsulan el resultado de un Action. Los Actions de la aplicación simplemente devolverán un String en sus métodos. Un Action puede devolver diferentes resultados luego de su ejecución. Cada uno de estos resultados se corresponde con un Result, previamente configurado en Struts2. La configuración de cada Result determina principalmente: el tipo de vista a mostrar (JSP, Velocity Templates, FreeMarker, entre otros), el recurso asociado a dicha vista, el nombre asociado al Result (mediante este y el resultado del Action se determina el Result a utilizar).

En resumen1. Llega un Request a la aplicación.

2. El Request es interpretador por el DispatcherFilter y determina que Action y que conjunto de Interceptors invocar.

3. Cada Interceptor ejecuta sus acciones previas a la ejecución del método de Action a invocar

4. Es invocado el método del Action.

5. Cada Interceptor ejecuta sus acciones posteriores a la ejecución del método de Action a invocar

6. Se examina el resultado obtenido del Action y se determina el Result correspondiente.

7. Mediante el Result determinado se genera la vista, y según la configuración definida sobre el se invoca el proceso de generación de la vista.

8. La vista generada retorna al cliente.

Configuración del framework Struts2 posee varios archivos de configuración: struts.xml: Es el principal archivo de configuración del framework. Aquí

definimos los ActionMapping de nuestra aplicación, su división en Package, la registración de los Interceptors, la asignación de los Interceptors a los Package, entre otras cosas.

struts-default.xml: Este archivo define una configuración básica de un Package del cual es conveniente que el resto de nuestro Packages hereden para obtener los beneficios del framework. Podemos redefinir esta configuración ubicando un archivo propio con el mismo nombre en el classpath.

struts.properties: Este es un archivo de properties que contiene un conjunto de pares key - valor que nos permiten definir un conjunto de parametros del framework. Este archivo es cargado por defecto por el framework (obteniendolo de struts-core.jar), pero podemos redefinir los

parametros ubicando el mismo en el classpath de la aplicación

Package Mediante los Packages podemos agrupar un conjunto de

ActionMapping que compartan la configuración. Por ejemplo, podemos definir los interceptors a aplicar sobre ellos, Results comunes, manejo de excepciones unificado, entre otras cosas.

En forma mas general, los Packages permite definir unidades reutilizables y sobreescribibles que agrupan interceptors, interceptor-stacks, action, results, result types. Se puede definir una jerarquia entre los Packages para reutilizar configuración, pueden existir package abstractos para luego reutilizar.

Las principales ventajas que proveen son: Reutilización de configuración. Modularización de la aplicación.

ActionMapping Un ActionMapping es un objeto que contiene la

información de configuración para el manejo de un conjunto de request. Se corresponde con el elemento <action>. En el se define:

El/los handler/s del request, el metodo a invocar. Tambien mantiene referencia a los Results definidos. A

partir del atributo namespace del Package en que esta definido, su atributo name, y el postfijo utilizado (por default .action) podemos identificar la expresion regular que debe cumplir el path del Request para que el framework decida su ejecución.

Namespace A los Package se les puede asignar un namespace que

indica un subcontexto de la aplicación web. El namespace define un prefijo para identificar al Package. Por ejemplo, dada la aplicación "pruebaStruts", definiendo un package con el atributo "namespace='/package1'", todas las urls del tipo "http://ip:puerto/pruebaStruts/package1/*" serán mapeadas a este package (o a todos los que tengan este namespace) en busca del action correspondiente.

Los namespace permiten evitar conflicto de nombres entre actions y modularizar nuestra aplicación.

Los Tags de Struts2 conocen los namespaces, asi que no es necesario incluirlos en los elementos de las paginas.

Struts.xml <struts> <package name="Userpackage" namespace="/dispatch" extends="struts-default"> <action name="User" class="example.dispatch.user.UserAction"> <result name="success">/dispatch/success.jsp</result> </action> <action name="addUser" method="add" class="example.dispatch.user.UserAction"> <result name="success">/dispatch/success.jsp</result> </action> <action name="updateUser" method="update" class="example.dispatch.user.UserAction"> <result name="success">/dispatch/success.jsp</result> </action> <action name="deleteUser" method="delete" class="example.dispatch.user.UserAction"> <result name="success">/dispatch/success.jsp</result> </action> </package> </struts>

Interceptors Stuts2 permite utilizar interceptors para los Actions.

Mediante estos podemos ejecutar código antes y después de la ejecución de un Action. Esto nos permite agregar funcionalidad útil para todos los Actions de nuestra aplicación.

Struts2 trae definidos un conjunto de interceptors por defecto, que le permite realizar un conjunto de acciones sobre los Action, el Request y el Response. Estas acciones son, por ejemplo: validaciones de los parámetros de entrada, inyección de dependencias, logueo, etc.

Todos los Interceptor deben implementar la interfaz Interceptor

Declaración Interceptor

public interface Interceptor extends Serializable {void destroy(); void init(); String intercept(ActionInvocation invocation) throws Exception;

}• Método init: Es llamado luego de que Interceptor sea

creado. • Método destroy: Es utilizado para que el Interceptor

libere los recursos que ha alocado. • Método intercept: Es el que debe contener la lógica a

ejecutar antes y despues de la llamada de un método.

Registro de Interceptors

<struts> ... <package> ...

<interceptors> <interceptor name="security"

class="com.company.security.SecurityInterceptor"/> </interceptors>

... </package>

... </struts>

Interceptor stacks. Los Interceptor Stacks, nos permiten agrupar un conjunto de

interceptors, en un solo paquete para ser utilizados en conjunto. (dentro de un stack podemos incluir otro stack).

Registro de Interceptor Stacks<struts> ...

<package> ...

<interceptors> <interceptor name="security" class="example.interceptor.SecurityInterceptor"/>

<interceptor name=”logueo” class=”example.interceptor.LoguerInterceptor”/>

<interceptor-stack name="secureStack">

<interceptor-ref name="security"/>

<interceptor-ref name="logueo"/>

</interceptor-stack>

</interceptors>

... </package>

... </struts>

Utilización de Interceptors Para utilizar los interceptors definidos, podemos: Definirlos en el package como default interceptor

<struts> ...

<package> ...

<default-interceptor-ref name="secureStack"/>

... </package>

... </struts>

Definirlos en cada Action <struts> ...

<package> ... <action name="loging" class="example.action.Login"> <result name="success">

...</result>

<interceptor-ref name="secureStack"/>

</action>

... </package>

... </struts>

Resumen de ejecución1. Llega un Request a la aplicación.

2. El Request es interpretador por el DispatcherFilter? y determina que Action y que conjunto de Interceptors invocar.

3. Cada Interceptor ejecuta sus acciones previas a la ejecución del método de Action a invocar Si el Interceptor el Action: Se ubicara en la session del usuario un objeto Locale para utilizar.

r Si el Interceptor ValidationInterceptor intercepta el Action: Se ejecutan la reglas de validación definidas sobre el Action

r Si el Interceptor AnnotationValidationInterceptor intercepta el Action: Se chequea en el método a invocar del Action si tiene la anotación @SkipValidation, en cuyo caso no se realizan validaciones

4. Es ejecutado el método anotado con @Before en el Action

5. Es invocado el método del Action.

6. Es ejecutado el método anotado con @After en el Action

7. Es ejecutado el método anotado con @BeforeResult en el Action

8. Cada Interceptor ejecuta sus acciones posteriores a la ejecución del método de Action a invocar Si el Interceptor ModelDrivenInterceptor? intercepta el Action: Luego de la ejecución del Action se ubicara en el value stack el

modelo que provee el Action.

e Si el Interceptor ParametersInterceptor? intercepta elAction: Los parametros provenientes del Request se ubican en el value stack

t Se examina el resultado obtenido del Action y se determina el Result correspondiente.

s Mediante el Result determinado se genera la vista, y según la configuración definida sober el se invoca el proceso de generación de la vista.

La vista generada retorna al cliente.