No todo el monte es orégano

Filtros de javax.servlet

2009-05-18T08:19:00.000-07:00

En este post se explica como crear un elemento que puede ser de gran utilidad para nuestras aplicaciones web como es el Filtro de la Interfaz javax.servlet.Filter. Con un filtro podemos indicar a nuestra aplicación web que realice una acción intermedia (que nosotros indiquemos como veremos a continuación) al flujo de trabajo de la aplicación.

Para explicar su funcionamiento vamos a suponer que tenemos una aplicación desarrollada bajo el framework Struts y en la que tenemos la siguiente estructura de ficheros y paquetería:

MiAplicacion
- src
- MiAplicacion.Action (Package)
- MyAction1 (Clase Action de Struts)
- MiAplicacion.ActionForm (Package)
- MyActionForm (Clase Action Form de Struts)
- WebContent
- jsp
- index.jsp (Pagina principal formulario con un campo de texto y un boton para enviar el valor del campo de texto al MyAction1, y que es recogido por MyActionForm)
- welcome.jsp (Pagina a la que se redirecciona despues de llamar a MyAction1 y si el filtro no altera el flujo de trabajo de la aplicación)
- mensaje.jsp (Pagina que se mostrará cuando se cumpla cierta condicion en el filtro)
- WEB-INF
- struts-config.xml
- web.xml

Suponiendo que el mapeo de los Action y Action Form es correcto (se realiza en el fichero struts-config) vamos a declarar nuestro filtro en el proyecto, a implementar su código y a indicar la acción que realiza cuando se ejecute el filtro.

Para ello, creamos una nueva clase (POJO) que implemente la interfaz javax.servlet.Filter,
(en mi caso en el paquete: MiAplicacion.Filters quedando la estructura como MiAplicacion.FIlters.MiFiltro). Puesto que es una interfaz, nuestro IDE nos pedirá que declaremos los métodos obligatorios que debe contener nuestra clase MiFiltro.

Observamos que entre los métodos existe uno que se llama doFilter que es el que contendrá el código donde se efectuará la acción del filtro:

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException{...}

Nuestro código, por no complicar el programa y puesto que no es lo relevante en este post, simplemente recibirá un parámetro con un valor entero de la petición http por request
lo comparará con cero y en caso de ser menor o mayor efectuará una u otra acción. A continuación se muestra más detalladamente:

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
//EL siguiente codigo es necesario ya que los parametros no son HttpServlet sino Servlet

HttpServletResponse servletResponse =
(HttpServletResponse)response;

HttpServletRequest servletRequest =
(HttpServletRequest)request;

/*
Si el parametro enviado desde la jsp "index.jsp" es cero => se sigue
el flujo de trabajo normal de la aplicación como si no existiese filtro.
En cambio, si el parámetro contiene un valor distinto de cero => Se
redirecciona a la página "mensaje.jsp" alterando el flujo de trabajo de
la aplicación.
*/
if(request.getAttribute("parametro")!=null &&
request.getAttribute("parametro")==0)
{
chain.doFilter(request, response);
}
else
{
servletResponse.sendRedirect(servletRequest.getContextPath()+"/jsp/mensaje.jsp");
}

}//cierra método doFilter

Además de declarar nuestra clase del filtro e implementar el código que se va a ejecutar con el filtro, tenemos que indicar a la aplicación dónde va a ejecutarse nuestro filtro, es decir, en qué momento del flujo de trabajo queremos que se ejecute el código antes implementado. Para esto nos vamos al fichero web.xml e introducimos las siguientes etiquetas:

web-app
...

filter
filter-name mifiltro /filter-name
filter-class MiAplicacion.Filters.MiFiltro /filter-class
/filter

filter-mapping
filter-name mifiltro /filter-name
url-pattern *.do /url-pattern
/filter-mapping
...

Con estas etiquetas, por un lado declaramos la existencia de nuestro filtro en la aplicación (etiqueta filter con nombre del bean del filtro y clase del filtro), y por otro lado dónde queremos que se ejecute el filtro dentro del flujo de trabajo de nuestra aplicación(etiqueta filter-mapping con el nombre del bean del filtro al que hacemos referencia y url-pattern que indica que el filtro se ejecutará ANTES de cualquiera llamada a un fichero (loquesea=*)loquesea.do , es decir, un Action de nuestra aplicación).

Otra posible configuración podría ser poner en la etiqueta url-pattern el contenido *.jsp, coin lo que estariamos indicando que el filtro deberá ejecutarse ANTES de una llamada a un fichero de tipo loquesea.jsp, es decir una página jsp.

Entrada de Prueba

2009-05-17T12:35:00.001-07:00

Esta es una entrada de prueba

Múltiples struts-config.xml en mi aplicación

2009-05-17T08:56:00.000-07:00

En este post trato de explicar la forma de utilizar varios ficheros de configuración del framework Struts en nuestro proyecto de aplicación web.

Si tenéis una aplicación desarrollada bajo el framework Struts y que contiene un gran número de clases de tipo Action de Struts sobre todo, y a la hora de realizar el mapeo de estas clases en vuestro fichero struts-config.xml, os resulta un tanto difícil la comprensión o la búsqueda de las etiquetas , para facilitar la gestión del fichero podemos optar por:

1) Crer una lista de multiples strut-config separada por comas.
2) Modularizar nuestra aplicación, dividiéndola en distintos módulos para su configuración.

La opción (1), puede ser la alternativa más rápida puesto que sólo necesita crear un nuevo fichero de configuración (struts-config-nuevo.xml) e incluir la parte que queramos del mapeo, que ya teníamos en nuestro fichero strut-config.xml inicial o por defecto.

A continuación mostramos un ejemplo de cómo hacerlo:

Por un lado tenemos el fichero struts-config.xml sin dividir, es decir, con todos los Action de nuestra aplicación mapeados:

struts-config
data-sources
/data-sources
form-beans
form-bean name="formbean"
type="es.nodotodoelmonteesoregano.actionform.MyActionForm"
/form-bean
/form-beans

global-exceptions
/global-exceptions

global-forwards
/global-forwards

action-mappings

action path="/myAction1"
type="es.nodotodoelmonteesoregano.action.MyAction1"
scope="request"
forward name="confirmacion" path="/jsp/ejemplo1.jsp"/forward
/action

action path="/myAction2"
type="es.nodotodoelmonteesoregano.action.MyAction2"
name="formbean"
scope="request"
forward name="confirmacion" path="/jsp/ejemplo2.jsp" /forward
/action

/action-mappings
...
(Resto de la configuracion del strut-config que tengais)
...

Ahora vamos a proceder a divir nuestro mapeo del fichero struts-config.xml en 2 ficheros:

1º) Fichero struts-config.xml anterior:

struts-config
data-sources
/data-sources
form-beans
>>> AQUÍ YA NO ESTÁ EL MAPEO DEL ACTION FORM <<<
/form-beans

global-exceptions
/global-exceptions

global-forwards
/global-forwards

action-mappings

action path="/myAction1"
type="es.nodotodoelmonteesoregano.action.MyAction1"
scope="request"
forward name="confirmacion" path="/jsp/ejemplo1.jsp"/forward
/action

>>> AQUÍ YA NO ESTÁ EL MAPEO DEL 2º ACTION <<<
/action-mappings
...
(Resto de la configuracion del strut-config que tengais)
...

2º) Fichero strut-config-nuevo.xml, en la misma ruta que el fichero struts-config.xml:

struts-config
data-sources
/data-sources
form-beans
form-bean name="formbean"
type="es.nodotodoelmonteesoregano.actionform.MyActionForm"
/form-bean
/form-beans

global-exceptions
/global-exceptions

global-forwards
/global-forwards

action-mappings

>>> AQUÍ YA NO ESTÁ EL MAPEO DEL 1er ACTION <<<

action path="/myAction2"
type="es.nodotodoelmonteesoregano.action.MyAction1"
name="formbean"
scope="request"
forward name="confirmacion" path="/jsp/ejemplo2.jsp" /forward
/action

/action-mappings
...
(Resto de la configuracion del strut-config que tengais)
...

3º) También necesario para que nuestra aplicación reconozca que existen dos ficheros de configuración de struts, es indicar en nuestro fichero web.xml que existen estos 2 ficheros, de la siguiente forma:

web-app
...

init-param
param-name config /param-name
param-value
/WEB-INF/struts-config.xml , /WEB-INF/struts-config-nuevo.xml
/param-value
/init-param
...
/web-app

>>> ATENCIÓN A LA COMA (,) <<<

Con esto podemos tener más organizada nuestra aplicación y ayudar, sobretodo, a la hora de depurar y realizar siguimientos del flujo de trabajo que se efectúa en una aplicación implementada bajo el framework Struts.

Artifactory para crear nuestros repositorios

2009-05-12T13:10:00.000-07:00

En este post vamos a explicar de manera rápida qué es y cómo instalar Artifactory para poder crear repositorios de dependencias para Maven.

Artifactory es una herramienta que actúa como servidor de repositorios para Maven 2. Con su instalación podremos, entre otas cosas, crear repositorios de dependencias para Maven.

Podemos descargarlo desde http://www.jfrog.org/download.php (En mi caso, he descargado el fichero .zip)

Una vez descargado lo descomprimimos en alguna hubicación (En mi caso C:/, quedando C:\artifactory-2.0.5) .

Por otro lado tendremos que crearnos una variable de entorno del sistema (ARTIFACTORY_HOME) y añadirla a la variable PATH del mismo.

Por último cogemos el fichero con extensión .war que contiene la carpeta C:/artifactory-2.0.5/webapps (artifactory.war) y realizamos el despliegue de la aplicación, llevándolo a nuestro Tomcat.

Ahora, si arrancáis Tomcat podéis acceder al gestor de repositorios con la url:

http://localhost:8080/artifactory/

Repositorios Maven

2009-05-12T11:39:00.001-07:00

En este post se explica cómo utilizar un repositorio propio de dependencias, para almacenar los ficheros .jar de nuestros proyectos Maven.

Maven mete los jar en determinados sitios de forma que queden accesibles para otros proyectos Maven.

Por un lado hay un repositorio local de jars, en el mismo ordenador. Está en $HOME/.m2/repository. Aquí se van guardando todos los jar que se bajan automáticamente de internet y los de mis proyectos cuando yo lo indico. Este repositorio sólo está accesible para un usuario en un ordenador.

Por otro lado está internet, en el que hay jars típicos (log4j.jar, junit.jar, etc). Maven se baja de allí los jar cuando los necesita y los guarda en nuestro repositorio local.

Podemos configurar además un respositorio para el equipo de trabajo, de forma que los jar "oficiales" del proyecto se guardan allí y están disponibles para todos los ordenadores y usuarios de ese equipo de trabajo. (Ver Como crear y gestionar repositorios con Artifactory)

Partimos de que tengamos creado un repositorio propio (puede hacerse con Artifactory), por ejemplo:

 id nombre_asignado_por_artifactory /id


nombre nombre_asignado_por_artifactory /nombre


url http://localhost:8080/artifactory/nombre_repositorio /url

Ahora tendremos que configurar el fichero settings.xml (Yo lo tengo en "C:\apache-maven-2.1.0\conf") de Maven para la conexión con el repositorio, de manera que, editamos el fichero y añadimos las siguientes líneas dentro de la etiqueta :

server

id nombre_asignado_por_artifactory /id

username usuario_artifactory /password

password password_artifactory /password

/server

A continuación, configuramos el fichero pom.xml de nuestros proyectos para que por defecto genere los .jar en el repositorio que hemos creado y podamos compartirlo con los demás proyectos Maven, como antes se menciona. Editamos el fichero e introducimos:

project
...
distributionManagement

repository

id nombre_asignado_por_artifactory /id
nombre nombre_asignado_por_artifactory /nombre
url http://localhost:8080/artifactory/nombre_repositorio /url

/repository

snapshotRepository

id nombre_asignado_por_artifactory /id
nombre nombre_asignado_por_artifactory /nombre
url http://localhost:8080/artifactory/nombre_repositorio /url

/snapshotRepository

/distributionManagement
...
/project

Una vez hecho esto, con mvn deploy, se generan los jar del proyecto y se guardan en el repositorio indicado en la etiqueta distributionManagement.

Bienvenidos!

2009-05-08T13:30:00.000-07:00

Hola amigos, conocidos, compañeros, familiares y demás personas que visitais este blog!