JBossAS: Desarrollo con Java Server Faces es un curso en español para introducir la tecnología JSF en el desarrollo de interfaces en aplicaciones web y realizar despliegues en el servidor JBoss AS 4.0.5

1. JavaServer Faces (JSF)
Curso Práctico
Desarrollo del esqueleto de la Aplicación CaJsfWeb
Neodoo Microsystems S.L.
www.neodoo.es
manuel.aznar@neodoo.es
francisco.solans@neodoo.es
aitor.acedo@neodoo.es

2. Un poco de historia (I)
Java Server Faces es el
resultado de muchos años
desarrollando aplicaciones
Web utilizando la tecnología
Java

3. Un poco de historia (II)

4. ¿ Qué es JavaServer Faces ?
JavaServer Faces (JSF) es una framework para crear aplicaciones orientadas a la Web.
En cierto modo, JavaServer Faces es una combinación de las frameworks Struts y Swing:
De forma similar a Struts, JSF proporciona la gestión del ciclo de vida de la aplicación a través de un
servlet controlador.
Parecido a Swing, JSP proporciona un modelo de componentes con gestión de eventos y renderizado.

5. Aplicación CaJsfWeb (I)
Lo primero que tenemos que hacer cuando
vayamos a desarrollar una aplicación es
dibujar las páginas por las que estará
compuesta.
El esqueleto de la aplicación CaJsfWeb permite
autenticar a un usuario y efectuar las
siguientes tareas:
Modificar la contraseña.
Ver listado de clientes.
Aparecerá un listado de clientes pudiendo conocer si
se trata de una persona física o no.
Registrar Cliente.
Formulario para incluir dentro de nuestra BBDD la
información de un cliente nuevo.

6. Aplicación CaJsfWeb (II)
Autenticación al sistema:
Petición de login tras autenticación errónea:

7. Aplicación CaJsfWeb (III)
Menú principal:

8. Aplicación CaJsfWeb (IV)
Vista para el cambio de contraseña:

9. Aplicación CaJsfWeb (V)
Ver listado de clientes:

10. Aplicación CaJsfWeb (VI)
Registrar clientes nuevos en la BBDD

11. Configuración de Eclipse (I)
Para desarrollar la aplicación CaJsfWeb, utilizaremos
el IDE Eclipse y los plugins de entorno web:
Eclipse SDK 3.2.2
Disponible en:
www.eclipse.org/downloads/
Web Tools Platform (WTP).
Desde Eclipse accediendo a Help ­>
Software Updates > Find and Install...
seleccionando Search for new features to
install
Lista de mirrors: Callisto Discovery Site
Seleccionar Web and J2EE Development,
presionar Select Required.
Web Tools Platform (WTP) Updates.

12. Configuración de Eclipse (II)
Instalación del plug­in Subclipse, utilizado para
trabajar con Subversion dentro de Eclipse
Desde Eclipse accediendo a Help ­>
Software Updates > Find and Install...
seleccionando Search for new features to
install. Elegir New Remote Site...
Aceptamos la licencia y confirmamos la instalación en nuestra versión de Eclipse

13. Configuración de Eclipse (III)
Los servidores más comunes en las arquitecturas J2EE están embebidos en el IDE Eclipse por lo que es posible
tanto visualizar las trazas de log como controlar el servidor.
La configuración de un servidor externo a Eclipse es la solución más adecuada para realizar depuraciones.
Window­>Preferences­>Server­>Installed Runtimes

14. Proyectos Software Necesarios
Descargamos los siguientes proyectos para insertar las librerías necesarias en nuestro desarrollo web:
Añadir el driver JDBC de la base de datos (en nuestro caso MySQL) si no está ya en el servidor de
aplicaciones, en el CLASSPATH del sistema o <JAVA_HOME>/jre/lib/ext. Nos podremos bajar el driver
de http://dev.mysql.com/downloads/connector/j/5.0.html
Implementación JavaServer Faces (Elegir una de las dos):
MyFaces (Apache): MyFaces Core 1.1.5 Distributions de http://myfaces.apache.org/download.html
JSF RI (Sun): Descargar de https://javaserverfaces.dev.java.net
Descargar las Jarkarta Taglibs http://www.apache.org/dist/jakarta/taglibs/standard/
Añadir al proyecto standard.jar (Es una implementación Open Source de JSP Standard Tag Library (JSTL), version
1.1.2).

15. Generación Proyecto Nuevo (I)
Desde el IDE Eclipse, ir a File > New... > Project y en la ventana seleccionar
Web > Dynamic Web Project.
Crear un proyecto denominado CaJsfWeb.
Seleccionar como Target Runtime Apache Tomcat v5.5
Seleccionar JavaServer Faces v1.1 Project en Configurations.
Posteriormente, seleccionar Dynamic Web Module, Java 5.0 o 6.0
(para uso de extensiones del lenguaje y anotaciones) y
JavaServer Faces 1.1.
Context Root: CaJsfWeb, Content Directory: WebContent y Java Source
:
,
Directory: src
En la ventana JSF capabilities, si no existe ningún Implementation
Library, crearla importando las librerías del proyecto MyFaces o
similar.
En nuestro caso, utilizamos MyFaces Core 1.1.5. agregamos también la
librería standard.jar del proyecto Jakarta Taglibs.

16. Generación Proyecto Nuevo (II)
Hemos conseguido un esqueleto básico para
comenzar nuestra implementación del proyecto
CaJsfWeb.
CaJsfWeb
Existe un esqueleto ubicado en el servidor de
Subversion.
Es necesario instalar el plugin Subclipse para
tener soporte SVN (seguir las instrucciones
de la ficha Configuración de Eclipse (III))
Configuración de Eclipse (III)
Lo primero que vamos a desarrollar será la vista
utilizada para entrar en el sistema así como las
páginas jsp, que pueden ser el resultado de
introducir correctamente, o no, los datos dentro
del formulario.
Ir a File > New Project > SVN > Checkout Projects
from SVN e introducir los datos del
repositorio.
Nos podremos bajar las soluciones de los
ejercicios propuestos.

17. web.xml (I)
El fichero web.xml contiene la configuración inicial al
arrancar el desarrollo web.
El servlet de la implementación JSF controla las
URL's acabadas con una extensión determinada
(en este caso *.faces):
Si se indica solamente el contexto de la aplicación, la
página que se mostrará inicialmente será una de
las que se marquen en el bloque <welcome­file­list>
Mediante las secciones <servlet> y
<servlet>
<servlet­mapping> se configura el servlet.
<servlet­mapping>
Dado que el recurso indicado en la sección
<welcome­file­list> no puede ser procesado por
<welcome­file­list>
ningún servlet, es habitual dejarla con una
simple redirección.
En este caso, la primera página no puede pasar
por ningún servlet por lo que la llamada es
directamente al recurso.

18. web.xml (II)
Otros parámetros de configuración de JSF utilizados
en la aplicación CaJsfWeb:
Los ficheros de configuración utilizados por el servlet que
controla la implementación JSF se indican gracias
al parámetro javax.faces.CONFIG_FILES.
javax.faces.CONFIG_FILES
El número de ficheros dependerá de la complejidad de
la aplicación a desarrollar.
En nuestro caso simplemente vamos a utilizar el
primero, faces­config.xml

19. Creación de un Formulario (I)
Creamos una página jsp
que representará la
vista del formulario de
entrada a nuestra
aplicación:

20. Creación de un Formulario (II)
Lo primero que nos encontramos dentro del la página jsp es:
Estamos indicando al motor de JSP's que queremos utilizar dos librerías de etiquetas, html y core, la primera
html core
contiene todas las etiquetas necesarias para trabajar con los elementos típicos de HTML, como por ejemplo,
formularios... La librería core contiene todas las etiquetas propias de JSF, por ejemplo, etiquetas de
core
validación, etiquetas del controlador...
Esta etiqueta es muy importante ya que informa al contenedor de que los componentes de esta página van a ser
gestionados a través de JSF, gracias a ella el árbol de componentes puede ser construído o encontrado si la
vista ya había sido cargada con anterioridad.
Con la siguiente etiqueta le estamos diciendo a JSF que queremos representar un formulario en ese preciso
lugar de la vista, a través del atributo id JSF podrá identificar cada uno de los componentes dentro del árbol
id
que ha generado.

21. Creación de un Formulario (III)
Esta etiqueta lo único que hará será representar la cadena “Login” dentro de la página generada en nuestro
navegador.
A parte de representar una caja de texto dentro de la vista, esta etiqueta es importante por el hecho de que
vincula el contenido de la caja de texto con un campo nombre del bean que hemos denominado loginAction, que
nombre
loginAction
no viene a ser otra cosa que la clase LoginAction.
El contenido del atributo value, cuyo valor es #{loginAction.nombre}, es un ejemplo de uso de JSF EL, es decir,
value
#{loginAction.nombre}
JavaServer Faces Expression Language, utilizado para establecer una asociación entre la vista y el
controlador de nuestra aplicación.
Por último, pero no menos importante, tenemos la etiqueta commandButton que gracias a su atributo action
commandButton
action
vinculará el método login de la clase LoginAction con el botón que estará representado en la página.
login
LoginAction

22. Creación del Managed Bean (I)
Creamos la clase LoginAction dentro del paquete es.neodoo.cajsfweb.controller
LoginAction
Atributos:
Crear los métodos necesarios para poder acceder a los atributos:
Crear el método para vincularlo con el botón de someter (submit) del formulario:

23. Creación del Managed Bean (II)
El fichero faces­config.xml contiene la información relativa a la aplicación que estamos desarrollando.
Al abrir el fichero faces­config.xml, desde la ventana Faces Configuration puede elegir la pestaña Overview para
manipular de forma visual el fichero xml; en todo caso, siempre puede manipularse el fichero directamente
desde el código, seleccionando la pestaña Source. Aspecto inicial del fichero de configuración:

24. Creación del Managed Bean (III)
Registramos el managed bean que acabamos de crear dentro de faces­config.xml, seleccionando la pestaña
ManagedBean:
El contenido del fichero faces­config.xml pero esta vez en modo texto:

25. Reglas de Navegación (I)
Desde el IDE Eclipse, pulse sobre el fichero
WEB­INF/faces­config.xml y desde el panel Faces
Configuration seleccione la ventana 'Overview'.
'Overview'
En el caso de CaJsfWeb, el fichero faces­config.xml
faces­config.xml
contiene unas reglas que indican las secuencias
de navegación en la aplicación web.
Desde el IDE Eclipse, pulse sobre el fichero
WEB­INF/faces­config.xml y desde el panel Faces
Configuration seleccione la pestaña 'Navigation'.

26. Reglas de Navegación (II)
Los elementos XML generados dentro de faces­config por las reglas de navegación son:

27. Reglas de Navegación (III)
Hablaremos de navegación estática cuando solamente
existe una página destino que podemos alcanzar:
Diremos que la navegación es dinámica cuando existe
más de una página destino a la que podemos ir
desde la página origen:
Este caso es utilizado en la ventana de login, ya que
login
no sabremos hasta que se esté ejecutando la
aplicación que ventana tendremos que
representar después de entrar en la aplicación.
Este tipo de navegación estará implementado en la
regla de navegación que gestiona el
desplazamiento entre la vista loginNak y la vista
loginNak
login.

28. META­INF/context.xml
Para acceder a través de JNDI a la BBDD tenemos que añadir un elemento a la configuración de nuestro
desarrollo:
El fichero context.xml se encuentra ubicado dentro del directorio META­INF generado dentro de nuestro proyecto,
context.xml
el elemento Context es una copia del generado automáticamente por Eclipse dentro del fichero server.xml, que se
Context
server.xml
encuentra el servidor que hemos creado en la configuración de nuestro entorno de desarrollo.

29. Estructura de directorios
El proyecto CaJsfWeb contiene un directorio
WebContent con los recursos asociados a la web:
WebContent
En el directorio Java Resources, se almacena:
Java Resources
El código fuente de la aplicación en src.
src
Los contenidos web como imágenes, css, html, páginas
dinámicas, ...
Inclusión de las librerías necesarias para soportar JSF y
la Standard TagLib.
Los ficheros de configuración web.xml y
faces­config.xml están ubicados dentro de
WEB­INF.

30. Ejecución de CaJsfWeb (I)

31. Ejecución de CaJsfWeb (II)

32. Ejecución de CaJsfWeb (III)

33. Ejecución de CaJsfWeb (IV)

34. Ciclo de vida de JSF (I)
JSF gestiona las llamadas HTTP mediante 7 fases tal como indica el diagrama:

35. Ciclo de vida de JSF (II)
Fase Reconstituir el árbol de llamada:
Fase Gestionar los eventos de la llamada:
Crea un árbol de componentes para la página
solicitada.
Los eventos de la llamada se gestionan
llamando al método processEvents() de cada
processEvents()
componente que tiene una o más llamadas.
Fase Aplicar los valores de la llamada:
Los componentes pueden gestionar los eventos
directamente o delegando el evento a un
gestor de eventos.
Se efectúa una iteración en el árbol de
componentes y se ejecuta el método decode()
decode()
de cada componente. Este método extrae
información de la llamada y lo almacena en
el componente.
El método processEvents() devuelve un valor
processEvents()
booleano .Si es falso, el ciclo de vida salta a
la fase Procesar Validaciones; de otro modo,
el ciclo de vida avanza directamente a la
fase Renderizar la Respuesta.
Opcionalmente, los componentes pueden
delegar la descodificación a un
renderizador.
Para descodificar la información de la llamada,
los componentes o los renderizadores
pueden crear eventos de llamada. Estas
señales suelen indicar un cambio visual en
uno o más componentes.

36. Ciclo de vida de JSF (III)
Si se produce un error de conversión, la
implementación JSF invoca directamente la
fase Renderizar Respuesta.
Fase Procesar validaciones:
La implementación JSF invoca el método
validate() de cada validador.
validate()
Fase Invocar la aplicación:
Los validadores efectúan los chequeos y
devuelven un valor booleano del método
validate(). Si el método devuelve true, el ciclo
validate()
de vida procede normalmente; en otro caso,
la implementación JSF invoca directamente
a la fase Renderizar Respuesta.
Los eventos de formulario y comandos (links,
submit, ...) son gestionados en esta sección
por un gestor específico de la aplicación.
Generalmente estos gestores indican una
URL y la implementación JSF redirige la
llamada a este enlace.
Fase Actualizar el modelo de valores:
Fase Renderizar la respuesta:
Cada componente JSF puede ser asociado a un
objeto Java (objeto modelo). El método
updateModel() de los componentes realiza esta
updateModel()
transferencia y conversión. Los errores de
conversión pueden ocurrir durante esta fase
(paso de la request como String a objetos
Java).
Se genera el árbol de componentes de
respuesta y se envía la respuesta al cliente.

37. Ciclo de vida de JSF (IV)

38. Conversión (I)
Como el usuario de nuestra aplicación web va a introducir los datos en formato texto en el formulario, en
ocasiones los objetos que modelan nuestra lógica de negocio precisan objetos de otro tipo.
En este caso utilizamos un conversor estándar para poder trabajar con un tipo Date en la lógica aunque el
dato sea introducido en nuestro componente como un String.

39. Conversión (II)
Para crear un conversor personalizado deberemos de seguir la siguientes instrucciones:
Implementar el interfaz Converter (javax.faces.convert.Converter)
Implementar el método getAsObject, el cual convierte un campo de nuestro formulario (String) en un objeto
del tipo que deseemos.
Implementar el método getAsString, el cual convierte un objeto del tipo que nosotros necesitemos en un
String.
Registrar nuestro conversor personalizado en el contexto Faces.
Insertar el conversor en las vistas que lo necesitemos utilizando la etiqueta <f:converter/>

40. Conversión (III)

41. Validación (I)
Algo que caracteriza a prácticamente todos los formularios que podamos desarrollar es el hecho de que los
datos que introducimos tienen que cumplir una serie de requisitos, JSF proporciona un mecanismo muy
sencillo de añadir reglas de validación a nuestros campos.
Existen 4 tipos diferentes de validación:
Validación intrínseca de los componentes
Validación a nivel de aplicación
Componentes con validación personalizada (los cuales implementan el interface Validator)
Métodos de validación implementados en los beans de la lógica de negocio

42. Validación (II)
Para crear componentes que posean una validación propia deberemos seguir los siguientes pasos:
Crear una clase que implemente el interfaz Validator (javax.faces.validator.Validator)
Implementar el método validate.
Registrar el validador personalizado en el fichero faces­config.xml
Utilizar la etiqueta <f:validator/> dentro de nuestras vistas
<f:validator/>

43. Validación (III)

44. Arquitectura MVC de JSF

45. Seguridad (I)
La seguridad se incluye en la aplicación CaJsfWeb restringiendo unas zonas de acceso por usuario
modificando los siguientes ficheros de configuración:
web.xml
context.xml
Para completar la seguridad, sería recomendable incorporar un certificado SSL al servidor web Apache en vez
de incluirlo en el contenedor / servidor J2EE.
Apache dispone de más funcionalidades y módulos para procesar las URL's.

46. Seguridad (II)
Configuración del fichero web.xml para implementar el mecanismo de seguridad:
Configuración del fichero tomcat­users.xml para implementar el mecanismo de seguridad:
tomcat­users.xml

47. Integración JMS
Hay determinadas acciones asociadas a las páginas web que en caso de tardar excesivo tiempo, darán un
time­out en el navegador del cliente.
Por regla general, suelen ser tareas que tardan más tiempo que el time­out definido en el navegador por lo
que la petición de la Request es detenida.
En la aplicación CaJsfWeb, existen 2 tareas que se pueden ejecutar en paralelo, es decir dejar la tarea en
background para que el servidor la ejecute cuando pueda. El cliente recibirá directamente la siguiente
página y se le informará que en el menor tiempo posible se efectuará la labor solicitada:
Ejemplo aplicaciones:
Creación del PDF del acta cerrada.
Envío de email para recordar password.

48. Arquitectura J2EE
En el caso de CaJsfWeb y por el hecho de usar servicios de mensajería asíncrona, Apache Tomcat se queda
'limitado' puesto que no dispone de este servicio.
Es necesario utilizar de forma complementaria el sistema de mensajería JMS a través de JBoss AS.
Según la distribución de los elementos de la arquitectura J2EE, podemos emplear Apache Tomcat de
forma aislada o el que viene integrado en JBoss AS.

49. Comparativa Struts – JSF (I)
Arquitectura de la framework Struts (Patrón MVC):
Arquitectura
Struts

50. Comparativa Struts – JSF (II)
Struts soporta redirecciones dinámicas a través
de forward:
El desarrollador ha de completar una clase que
extiende de Action:

51. Comparativa Struts – JSF (III)
Arquitectura de la framework JavaServer Faces (Patrón Page Controller Pattern):
Arquitectura
JavaServer Faces

52. Comparativa Struts – JSF (IV)
JSF soporta la navegación configurando el fichero de
configuración faces­config.xml:
Navegación dinámica:
Navegación dinámica
Página JSP:
Clase con la acción:
Al contrario que Struts, la navegación es aplicada a
nivel de página y la acción puede ser
independiente:
Navegación estática:
Navegación estática

53. Bibliografía
MySQL ­ http://dev.mysql.com/doc/refman/5.0/es/index.html
Data Access Object ­ http://es.wikipedia.org/wiki/Data_Access_Object
Etiquetas HTML en JSF ­ http://www.exadel.com/tutorial/jsf/jsftags­guide.html