Manual 2015-I 06 Proyecto Empresarial (CI) (0780)

Proyecto
Empresarial
PROYECTO EMPRESARIAL
CARRERA DE COMPUTACIN E INFORMTICA
CIBERTEC
PR OY EC T O E MP R ES A R I AL
ndice
Presentacin
Red de contenidos
5
7
Unidad de Aprendizaje 1
JAVA PERSISTENCE API

1.1 Tema 1 : Introduccin al API de Persistencia JPA
1.1.1 : Entidad
1.1.2 : Metadata
1.1.3 : EntityManager
1.1.4 : Unidad de Persistencia
1.1.5 : Operaciones bsicas
1.1.6 : Transacciones
1.1.7 : Ciclo de Vida de una Entidad
9
12
12
13
14
15
17
19
19
1.2 Tema 2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
:
:
:
:
:
:
OR-Mapping con JPA
1.3 Tema 3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
:
:
:
:
:
:
:
:
Relaciones entre entidades
Conceptos bsicos
Relacin Many To One
Relacin One to One
Bidireccionalidad de la relacin One-To-One
Relacin One To Many
Relacin Many To Many
Opciones de Fetch
38
38
40
42
43
44
46
49
1.4 Tema 4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.6
:
:
:
:
:
The Java Persistence Query Language.

Introduccin a JP-QL
Consultas dinmicas
Consultas nombradas
Uso de parmetros
Ejecucin de Queries
Sintaxis de JPQL
51
51
56
58
60
61
63
23
23
28
28
32
35
Anotaciones
Manejo de la Llave Primaria
Generacin de la Llave Primaria
Llave Primaria Compuesta
Objetos Embebidos
JAVA SERVER
2.1 Tema 5 :
2.1.1 :
2.1.2 :
2.1.3 :
2.1.4 :
2.1.5 :
2.1.6 :
2.1.7 :
CIBERTEC
FACES 2
Fundamentos de JSF
Introduccin a JSF
Arquitectura de JSF
Ciclo de vida de un request
Facelets
Managed Bean
Lenguaje de Expresiones JSF
Backing Beans
69
72
72
73
77
81
89
92
95
2.2 Tema 6 : Componentes de Interfaz de usuario

2.2.1 : Introduccin
2.2.2 : Arquitectura de Componentes UI
2.2.3
Librera Core
2.2.4
Librera HTML
2.2.5
Librera User Interface
2.2.6
Librera de Componentes Compuestos
97
97
98
102
108
117
117
2.3 Tema 7 : Conversiones, Validaciones y Eventos

2.3.1 : Introduccin
2.3.2 : El sistema de Conversin de JSF
2.3.3
El sistema de Validacin de JSF
2.3.4
El sistema de Mensajes de JSF
2.3.5
El modelo de Eventos de JSF
119
119
119
122
123
131
2.4 Tema 8
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
127
127
136
137
141
148
:
:
:
:
:
:
Integracin JSF y JPA

JSF y AJAX
Integracin JSF + JPA
Empleando otras implementaciones de JSF
Tablas JSF: Facets, dataTable y panelGrid
Mantenimiento de tablas
SPRING FRAMEWORK
3.1 Tema 9 : Spring Core
3.1.1 : Introduccin
3.1.2 : Arquitectura
155
157
157
161
3.2 Tema 10 : Spring Web

3.2.1 : Introduccin
3.2.2 : Configuracin
164
164
164
3.3 Tema 11 : Spring Mdulos

3.3.1 : Spring security
174
174
CIBERTEC
Presentacin
El curso de Proyecto Empresarial pertenece a la lnea de Programacin dentro de la

Carrera de Computacin e Informtica y brinda un conjunto de conocimientos y
herramientas que permitirn a los alumnos poder desarrollar aplicaciones web de ncapas utilizando los frameworks Java : Java Persistence API ( JPA ), Java Server Faces
( JSF ) y Spring Framework.
El manual del curso ha sido diseado bajo la modalidad de Unidades de Aprendizaje, las
que desarrollan determinados temas a lo largo de las semanas establecidas para el
dictado del curso. Cada captulo del manual indica los temas a ser tratados, los logros
que se deben alcanzar y los contenidos que se deben desarrollar. Finalmente, se
encontrar las actividades recomendadas que el alumno deber desarrollar para
reforzar lo trabajado y aprendido en la clase. Se incluye bibliografa y recursos de
internet que puede colaborar en el logro de un autoaprendizaje efectivo.
El curso es eminentemente prctico, pero requiere horas adicionales de investigacin y
prctica por parte del alumno. Se inicia con un los conceptos de OR-Mapping con la
especificacin JPA (Java Persistence API) y su implementacin en EclipseLink: se
abordan las anotaciones, mapeo y relaciones entre entidades as como los fundamentos
bsicos de JP-QL para la construccin de consultas. Luego, la segunda unidad del
manual aborda la especificacin JSF (Java Server Faces) tratando de abarcar gran
parte de la funcionalidad que proporciona. Finalmente, se aborda en la tercera unidad el
framework de Spring: Arquitectura, Web y Security.
CIBERTEC
CIBERTEC
Red de contenidos
Proyecto Empresarial
Java
Persistence
API
(JPA)
Spring
Spring Core
Java Server
Faces
(JSF)
Tpicos
avanzados de
JSF
Spring Web
Conversiones,
Validaciones
y Eventos
Spring Mdulos
Introduccin a
la API de
Persistencia
Componentes
de Interfaz de
usuario
OR-Mapping
con JPA
Arquitectura de
JSF, Configuracin
y estructura bsica
Relaciones
entre
entidades
Lenguaje de
Consultas
JPQL
CIBERTEC
CIBERTEC
UNIDAD
1
JAVA PERSISTENCE API
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno puede realizar transacciones y consultas
para reportes usando JPQL a nivel empresarial.
TEMARIO
1.1 Tema 1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.1.7
:
:
:
:
:
:
:
:
Introduccin al API de Persistencia JPA

Entidad
Metadata
EntityManager
Unidad de Persistencia
Operaciones bsicas
Transacciones
Ciclo de Vida de una Entidad
1.2 Tema 2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
:
:
:
:
:
:
OR-Mapping con JPA

Anotaciones
Manejo de la Llave Primaria
Generacin de la Llave Primaria
Llave Primaria Compuesta
Objetos Embebidos
1.3 Tema 3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
:
:
:
:
:
:
:
:
Relaciones entre entidades

Conceptos bsicos
Relacin Many To One
Relacin One to One
Bidireccionalidad de la relacin One-To-One
Relacin One To Many
Relacin Many To Many
Opciones de Fetch
CIBERTEC
1.4 Tema 4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.6
:
:
:
:
:
10
The Java Persistence Query Language.

Introduccin a JP-QL
Consultas dinmicas
Consultas nombradas
Uso de parmetros
Ejecucin de Queries
Sintaxis de JPQL
ACTIVIDADES PROPUESTAS
Reconocer las clases de la API Persistencia JPA

Los alumnos escriben clases Java, las convierten en Entidades JPA y
trabajan con tablas relacionales.
Las alumnos desarrollan aplicaciones Java stand-alone haciendo uso de
entidades JPA.
Implementar inserciones de sentencias JPQL a la base de datos.
Implementar consultas y transacciones de sentencias JPQL a la base de
datos.
Implementar inserciones de sentencias JPQL a la base de datos.
Implementar consultas y transacciones de sentencias JPQL a la base de
datos.
CIBERTEC
CIBERTEC
11
12
1.1. INTRODUCCIN AL API DE PERSISTENCIA JPA

La tcnica que permite acortar las diferencias entre el modelo relacional y el modelo
de objetos se conoce como ORM (Mapeo Relacional a Objetos). La idea bsica se
sustenta en que para mapear los conceptos de un modelo al otro (o viceversa) se
requiere de un mediador que maneje de forma automtica la transformacin.
La historia de JPA se origina en dos frameworks de persistencia bastante utilizados:
en el lado propietario exista TopLink mientras que en el lado open estaba Hibernate.
JPA es una especificacin basada en el JSR 220 conocido como Enterprise Java
Bean 3.0 (http://jcp.org/en/jsr/detail?id=220 ).
Al ser una especificacin (o un conjunto de APIs) est sujeta a diversas
implementaciones de diversos fabricantes. La idea principal es que sea un Framework
ligero, basado en POJOs y pueda enfrentar desafos de arquitectura e integracin en
aplicaciones empresariales.
Algunas implementaciones de JPA:
Hibernate
http://www.hibernate.org/
TopLink
http://www.oracle.com/technetwork/middlew
are/toplink/overview/index.html
OpenJPA
http://openjpa.apache.org/
EclipseLink
http://www.eclipse.org/eclipselink/
1.1.1. Entidad
El concepto de Entidad fue introducido por Peter Chen en un documento llamado
The Entity-relationship model Howard a unified view of data publicado en ACM
Transactions on Database Systems en el ao de 19761.
En dicho documento, se describa a las entidades como cosas que tenan atributos y
relaciones con la expectativa de que dichos atributos y relaciones pudieran ser
almacenados en la base de datos.
En la actualidad, dicha definicin es vigente dado que cualquier objeto dentro de una
aplicacin JPA puede ser una entidad, hay que definir las caractersticas que debe
poseer una Entidad:
Persistencia: las entidades pueden ser manipuladas para recuperase en

memoria o ser grabadas en un almacn de datos.
Una copia del documento se puede obtener en el enlace:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.1085&rep=rep1&type=pdf
CIBERTEC
13
Identidad: significa que las entidades tienen un identificador que permite

emplearlas de manera inequvoca y diferenciarlas de otras instancias de la
misma entidad. El identificador de la entidad es equivalente a la llave primaria
de una tabla en la base de datos.
Transaccionalidad: Todas las operaciones (insertar, modificar o eliminar)

deben realizarse dentro de un contexto transaccional debido a que se requiere
de una transaccin para que los cambios sean grabados en la base de datos.
Granularidad: Las entidades son objetos que pertenecen a un dominio de

negocio, poseen un conjunto de estados y por tanto son relevantes para la
aplicacin (no se trata de objetos con tipo primitivo, sino de objetos ms
complejos).
1.1.2. Metadata
Cada entidad tiene asociado una metadata que la describe. Dicha informacin puede
estar almacenada dentro de la entidad Java o puede existir en un archivo externo: en
ambos casos, esa informacin no se almacena en la base de datos.
Existen dos maneras de especificar la metadata:
Usando Anotaciones
Usando XML
Las anotaciones fueron introducidas en la versin JAVA EE 5 y permiten que la

metadata est incorporada dentro del cdigo fuente Java.
El uso de las anotaciones requiere que se importe el paquete javax.persistence.*
dentro de la clase Java que representa a la Entidad.
El uso de XML es una opcin alternativa a las anotaciones, aunque su lectura puede
resultar compleja para proyectos grandes.
Un JavaBean cualquiera como el siguiente
Se puede convertir en entidad, simplemente agregndole las anotaciones:

@Entity
@Id
CIBERTEC
14
No se debe olvidar que al ser un JavaBean, sigue las reglas de este (con los
getter/setter).
1.1.3. EntityManager
La mayora de llamadas a las APIs de JPA se encapsulan dentro de lo que se conoce
como Entity Manager y mediante el cual se puede alcanzar a la base de datos.
Esta encapsulacin es implementada dentro de una interface conocida como
EntityManager que es la que ejecuta todo el trabajo de persistencia. Por tanto, una
entidad mientras que no se trabaje con el Entity Manager es un objeto Java simple
como cualquier otro.
Cuando el Entity manager obtiene una referencia a una Entidad, se dice que dicha
entidad est en estado managed
El conjunto de entidades en estado managed dentro de un Entity Manager se conoce
como persistence context.
Los Entity Managers son configurados para trabajar con determinados tipos de
objetos, bases de datos y son implementados por un proveedor (provider) conocido
como persistence provider. En trminos prcticos este provider es la
implementacin de la especificacin JPA.
Los Entity Managers se generan a partir de una factora de tipo
EntityManagerFactory, que genera una especie de plantilla para la persistencia, pero
toma la configuracin particular desde una unidad de persistencia conocida como
persistence unit, la cual contiene la configuracin implcita o explcita (con un
nombre asociado ) para las entidades y para el Entity Manager.
El grfico2 resume las relaciones entre los conceptos mencionados:
FUENTE: JPA 2: Mastering the Java Persistence API, pg 23.
CIBERTEC
15
Un Entity Manager se obtiene de la siguiente forma:

Nombre de la persistence unit
Debe ser el mismo que aparece
en el archivo persistence.xml
Clase esttica
Variable con el Entity Manager cargado
1.1.4. Unidad de Persistencia

La configuracin de una unidad de persistencia se escribe en un archivo llamado
persistence.xml, el cual debe estar ubicado dentro del folder META-INF de un
proyecto Java.
Cada unidad de persistencia tiene un nombre, el cual es referenciado por la factora al
momento de pedirle que genere un EntityManager.
Un archivo persistence.xml puede contener una o ms unidades de persistencia,
siendo cada una diferente de la otra.
La estructura bsica de un archivo persistence.xml es la siguiente:
CIBERTEC
16
Debido a que es un archivo XML, debe tener un DTD:
Luego, viene la definicin de la Unidad de persistencia, el proveedor y las clases Java

definidas como entidades:
Nombre de la persistence unit
El valor de RESOURCE_LOCAL indica que la conexin a la base de datos se realizar

desde la misma aplicacin (No emplea Pool de conexiones).
Despus, se definen las propiedades de conexin a la base de datos:
CIBERTEC
17
Finalmente se cierran los tags XML:
Observe que las propiedades JDBC (javax.persistence.jdbc.*) han sido estandarizadas

en JPA 2.0. En versiones anteriores de JPA, esas propiedades eran definidas por cada
Persistence Provider.
1.1.5. Operaciones bsicas

Para aquellos desarrolladores acostumbrados al SQL en bases de datos relacionales,
la equivalencia es sencilla en JPA:
SQL INSERT = Mtodo Persist
SQL SELECT = Mtodo Find ( o tambin puede usarse el SELECT JPQL )
SQL UPDATE = Mtodo Merge
SQL DELETE = Mtodo Remove
El persist de una entidad significa crear un objeto en memoria y luego almacenarlo

en la base de datos para recuperarlo posteriormente. Como se ha mencionado,
equivale a insertar uno o ms registros en la base de datos.
Se instancia el objeto
Java
Se cargan los valores
de los atributos
Se ejecuta el mtodo persist

mediante el EntityManager
Si ocurre un error durante la ejecucin del persist, se lanza la excepcin
PersistenceException, la cual debe ser propagada, debiendo ser manejada por el
programa.
CIBERTEC
18
Para ubicar a una Entidad empleando el mtodo find, generalmente se requiere solo
una lnea de cdigo:
Clase de la Entidad a ser ubicada
Evita hacer un cast
Llave primaria de la Entidad
variable con el EntityManager cargado
Si la entidad con la llave primara indicada no existe, el EntityManager devolver NULL.

La aplicacin debe verificar el valor antes de usar la variable emp en el caso del
ejemplo.
Para eliminar una entidad, se hace uso del mtodo remove. Sin embargo se debe
tener en consideracin que para eliminar una entidad en JPA, primero debe colocarse
en estado managed, es decir, debe cargarse al contexto de persistencia.
Se requiere cargar la entidad
Como se mencion anteriormente, si la entidad no existe el EntityManager devolver

NULL, por lo que se debe evaluar dicha condicin antes de invocar al mtodo
remove.
Si se enva un valor de NULL al remove, JPA
java.lang.IlegalArgumentException.
lanzar
la
excepcin
Para actualizar atributos de una entidad, se emplea el mtodo merge. Se requiere

ubicar a la entidad antes de actualizarla:
En este ejemplo, se est actualizando el apellido del empleado con ID = 8.
CIBERTEC
19
1.1.6. Transacciones
El nico mtodo que puede estar fuera de una transaccin es el find dado que no
cambia atributos de las entidades.
En una aplicacin Java StandAlone (Java SE), se debe invocar el contexto
transaccional de forma explcita, mientras que en una aplicacin Java EE, se asume
que el container proporciona dicho contexto transaccional.
Se inicia una transaccin
Se inicia finaliza la
transaccin
1.1.7. Ciclo de Vida de una Entidad

JPA proporciona unos mtodos denominados callbacks (listeners) para ejecutar
acciones en los diferentes estados que pueden suceder dentro del ciclo de vida de una
entidad. Por ejemplo, imagine que desea actualizar una entidad, pero antes de hacerlo
debe verificar que algunos datos estn presentes.
En el grfico, se puede apreciar que una entidad no existe hasta que se distancia el
objeto y se graba en la base de datos. De ah, pasa al estado manejado o
administrado por el EntityManager y, luego de ello, se puede remover, actualizar,
liberar (detach) o incluso volver a leer (refrescar).
CIBERTEC
20
Las anotaciones que proporciona JPA para manejar los Callbacks son:
@PostLoad: Se ejecuta luego de un refresh a la entidad.

@PrePersist: Se ejecuta antes de insertar la entidad.
@PostPersist: Se ejecuta despus de haber insertado la entidad.
@PreUpdate: Se ejecuta antes de un update a la entidad.
@PostUpdate: Se ejecuta despus de un update a la entidad.
@PreRemove: Se ejecuta antes de eliminar la entidad en la base de datos.
@PostRemove: Se ejecuta despus de haber eliminado a la entidad.
Los mtodos callback se pueden declarar dentro de la misma entidad o tambin en

una clase Java separada.
Por ejemplo, si de declaran dentro de la misma entidad:
CIBERTEC
21
En cambio, si se prefiere emplear una clase Java externa, sera as:

a) A la Entidad hay que agregarle la anotacin @EntityListeners para indicar cul
es la clase Java que contiene los mtodos callbacks.
b) Se debe crear una clase Java y escribir los mtodos que se requiere manejar
(con las anotaciones del caso).
CIBERTEC
22
Resumen
1.
Recordar que JPA es una especificacin, por tanto, tiene muchas

implementaciones. El desarrollador debe seleccionar una en particular, siendo las
ms conocidas: Open JPA, TopLink, EclipseLink e Hibernate.
2.
Diferenciar entre Entidades y Clases Java.
3.
Recordar la ubicacin del archivo persistence.xml que debe ir siempre dentro del
folder META-INF.
4.
Recordar para qu sirve el EntityManager y la persistence-unit.
5.
Las operaciones bsicas sobre una Entidad: find, persist, merge, remove
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta
unidad:
o
o
EclipseLink: http://www.eclipse.org/eclipselink/jpa.php
Entidades JPA: http://www.agiledata.org/essays/mappingObjects.html
CIBERTEC
23
1.2. OR-MAPPING CON JPA

1.2.1. Anotaciones
Las anotaciones pueden clasificarse en dos grupos:
Anotaciones lgicas describen el modelo de entidades desde el punto de vista
del modelamiento orientado a objetos. Constituyen una especie de metadata
del modelo.
Anotaciones fsicas estn relacionadas con el modelo en la base de datos

(modelo fsico) y tienen que ver con tablas, columnas, etc.
Las anotaciones dentro de una clase Java se pueden colocar a nivel de atributos o a
nivel de mtodos. Si se colocan a nivel de atributos se denomina Field Access
mientras que si se coloca a nivel de mtodos se denomina Property Access.
Anotacin de tipo
Field Access
Atributos de la clase
Es equivalente a:
Anotacin de tipo Property

Access
NOTA: Siempre va en el GETTER
En la especificacin de JPA 2.0 se introduce la anotacin @Access que permite

combinar los dos modos presentados en el ejemplo. Esta anotacin permite sobre
escribir el modo de acceso por defecto, aunque no es muy usual hacerlo.
Para definir una entidad basta con emplear la anotacin @Entity y la anotacin @Id.
CIBERTEC
24
Anotacin @Table
Por defecto no es necesario incluir ninguna anotacin para referenciar a una tabla.
JPA asume que la tabla se llama igual que la clase Java en donde se define la entidad.
Sin embargo, si se desea especificar un nombre de tabla en particular para asociarlo
con la entidad, es preciso utilizar la anotacin @Table con el parmetro name
respectivo.
Se puede indicar adems el esquema de base de datos con el atributo schema (para
aquellos motores de base de datos que lo soporten):
Se debe tener cuidado con el uso de maysculas y minsculas, pues muchos

manejadores de bases de datos no son sensibles a esto.
Anotacin @Basic
Cuando se persiste una propiedad de una entidad, el persistente provider verifica
que el tipo de dato corresponda a un tipo soportado y trata de pasarlo hacia la base de
datos va el driver JDBC.
Los tipos de datos soportados son:
Tipos primitivos
Clases que encapsulan a tipos
primitivos
Arreglos de bytes y caracteres
Nmeros
Cadenas de caracteres
Tipos de datos que manejan fechas
byte, int, short, long, boolean, char, float

double
Byte, Integer, Short, Long, Boolean,
Character, Float, Double
byte[], Byte[], char[], Character[]
java.math.BigInteger, java.math.BigDecimal
java.lang.String
java.util.Date, java.util.Calendar
CIBERTEC
Java
Tipos de datos que manejan fecha
JDBC
Tipos enumerados
Objetos serializables
25
java.sql.Date, java.sql.Time,
java.sql.Timestamp
Cualquiera
Cualquiera
Se debe tener cuidado con el comportamiento del driver JDBC cuando los tipos de
datos no coinciden entre lo que se define en la entidad y lo que soporta la base de
datos, pues el driver intentar ejecutar la mejor conversin posible.
La anotacin @Basic (que es opcional) se utiliza para indicar de forma explcita que
dicho atributo debe ser almacenado en la base de datos.
Anotacin @Transient
Se emplea para marcar aquellos atributos de la entidad que NO deben ser guardados
en la base de datos.
Anotacin @Column
Es una anotacin de tipo fsico, pues indica las caractersticas fsicas de la columna
en la base de datos.
Si no se especifica para un atributo determinado marcado como persistente, JPA
asume que la columna se llama igual que dicho atributo. En cambio, si la columna
tiene un nombre diferente, se deber especificar con el uso de la anotacin @Column.
Los elementos que acompaan a la anotacin @Column son los siguientes:
CIBERTEC
Elemento
26
Descripcin
String
(Opcional)
columnDefinition Es el fragmento de SQL utilizado para generar el DDL de la
columna (depende del manejador de base de datos)
boolean
(Opcional) Indica si la columna ser incluir dentro de una
insertable
sentencia SQL INSERT generada por el Persistence Provider.
int length
(Opcional) Indica la longitud de la columna en la tabla y
funciona nicamente cuando la columna es un String o cadena
de caracteres.
String name
(Opcional) Indica el nombre de la columna. POr defecto se
asume que la columna se llama igual que el atributo de la
entidad.
boolean nullable
(Opcional) Indica si la columna permite valores nulos.
int precision
(Opcional) Indica la precisin para una columna numrica
(vlido solo para columnas decimales).
int scale
(Opcional) Indica la escala para una columna numrica (vlido
solo para columnas decimales).
String table
(Opcional) Indica el nombre de la tabla en donde se asocial la
columna.
boolean unique
(Opcional) Se emplea cuando la clave nica corresponde a
una sola columna.
boolean
(Opcional) Indica si la columna ser incluir dentro de una
updatable
sentencia SQL UPDATE generada por el Persistence
Provider.
Valor por
defecto
true
255
true
0
0
false
true
Ejemplo 1:
Ejemplo 2:
Anotacin @Lob
Para el manejo de objetos binarios (imgenes o archivos generalmente) se requieren
accesos especiales en el driver JDBC para efectuar conversiones entre el objeto Java
y la columna en la tabla de la base de datos.
La anotacin @Lob sirve para indicar que el atributo de dicha entidad requiere efectuar
las conversiones va JDBC.
Ahora bien, los campos LOB (acrnimo de Large Object) se pueden clasificar de dos
maneras, siendo el manejo de cada manera un tanto diferente:
CIBERTEC
Si el objeto es
Character Large Objets ( CLOB )
Binary Large Objects ( BLOB )
27
El tipo java a usar es

char[]
Character[]
String
byte[]
Byte[]
tipos serializables
En ambos casos, el driver JDBC es responsable de hacer las conversiones entre el

objeto Java y la base de datos.
Ejemplo:
Anotacin
Tipo de dato
Anotacin @Temporal
Sirve para especificar tipos de datos basados en el tiempo. Estos tipos de datos se
pueden clasificar en dos ramas: los que vienen del paquete java.sql y los que vienen
del paquete java.util.
En el paquete java.sql, los tipos se trabajan directamente:
java.sql.Date
java.sql.Time
java.sql.Timestamp
En cambio, en el paquete java.util:

java.util.Date
java.util.Calendar
CIBERTEC
28
Se debe especificar la anotacin @Temporal y adems especificar el atributo

TemporalType con uno de los tres valores que representan a cada uno de los tipos
java.sql (DATE, TIME o TIMESTAMP).
Ejemplo:
Anotacin
Tipo de dato
java.util.Date
Equivalencia JDBC
1.2.2. Manejo de la Llave Primaria

Cada Entidad debe tener una llave primaria. La anotacin empleada es @Id sobre el
atributo que contiene la llave. Adicionalmente, se puede usar @Column para asociar al
atributo con la columna en la tabla.
Una llave primaria se asume que es insertable, pero no puede ser nullable o
updatable por lo que se debe tener cuidado de no sobre escribir esos atributos salvo
excepciones muy especficas (cuando se manejan relaciones).
Los tipos de datos soportados para una llave primaria son:
Tipos primitivos
Clases de tipos primitives
Cadenas de caracteres
Nmeros grandes
Tipos basados en tiempo
byte, int, short, long, char

Byte, Integer, Short, Long , Character
java.lang.String
java.match.BigInteger
java.util.Date, java.sql.Date
1.2.3. Generacin de la Llave Primaria

Tambin, se conoce como Generacin del ID y se realiza mediante la anotacin
@GeneratedValue. En base a dicha anotacin, el Persistence Provider genera el ID
para cada entidad, y lo inserta en la columna respectiva.
Se debe tener en cuenta que dependiendo de la estrategia de generacin del ID, el
valor obtenido puede que no est disponible hasta que se ejecute un flush o un
commit a la transaccin.
CIBERTEC
29
Existen cuatro estrategias posibles (que son un tipo enumerado de GenerationType):

AUTO
TABLE
SEQUENCE
IDENTITY
ESTRATEGIA GenerationType.AUTO
Este tipo de estrategia delega en el Persistence Provider la seleccin de la mejor
forma de generacin de los ID. Cualquiera sea la forma elegida por el provider, se
confiar en los recursos de la base de datos para la obtencin de los IDs.
En el caso particular de EclipseLink con MySQL, la estrategia AUTO emplea una tabla
denominada sequence.
Ejemplo:
ESTRATEGIA GenerationType.TABLE
Esta estrategia es la ms flexible y portable, pues permite que la aplicacin genere
IDs diferentes de acuerdo a las necesidades.
La tabla requiere de dos columnas, una conteniendo el identificador para generar la
secuencia y la otra columna contiene el ltimo valor generado. Cada fila de la tabla es
un generador diferente para los IDs.
Un ejemplo sencillo es el siguiente:
CIBERTEC
30
Dado que no se ha especificado el nombre de un generador ni el nombre de una

tabla, el Persistence provider seleccionar sus propios valores. Lo ms comn es que
busque (la tabla debe existir en la base de datos) una tabla como la indicada en la
figura.
Qu sucede si se desea especificar una tabla en particular? Se debe emplear la
anotacin @TableGenerator.
Ejemplo:
El atributo allocationSize indica el incremento en la generacin del ID (para el caso

del ejemplo va de uno en uno). Por defecto el incremento es 50.
CIBERTEC
31
ESTRATEGIA GenerationType.SEQUENCE
Esta estrategia depende de las capacidades de la base de datos para manejar objetos
de tipo secuencia (caso de Oracle).
Al igual que en la estrategia TABLE, basta con escribir la anotacin para que el
Persistence Provider seleccione la mejor secuencia dentro de la base de datos.
Ejemplo:
Estrategia
Si se desea especificar una secuencia en particular, debe indicarse el generator y la

anotacin @SequenceGenerator. Se debe considerar que la secuencia debe existir
previamente en la base de datos (salvo que la opcin de generacin de DDL est
habilitada en nuestra aplicacin).
Ejemplo (la secuencia es para Oracle):
CIBERTEC
32
ESTRATEGIA GenerationType.IDENTITY
Esta estrategia aprovecha las facilidades de la bases de datos para utilizar columnas
de tipo autoincremento. Sin embargo, es menos eficiente porque el identificador
generado no est disponible hasta despus que ocurra el INSERT.
No requiere una anotacin para el generador dado que el campo autoincremental es
parte de la definicin de la tabla que corresponde a la entidad.
Ejemplo:
Estrategia
1.2.4. Llave Primaria Compuesta

En algunas situaciones, en donde se requiere que la llave primaria de una entidad est
compuesta de mltiples atributos, JPA proporciona dos formas de soportar esta
necesidad mediante las anotaciones:
@IdClass
@EmbeddedId
Se debe tener en cuenta que:

a) En ambos casos, se requiere de una clase Java externa que sea la que maneje
los atributos de la llave primaria.
b) La clase Java que maneja los atributos de la llave primaria, debe implementar
los mtodos equals () y hashCode () con el fin que el Persistence Manager
pueda almacenar e identificar las entidades.
c) La clase Java que representa a la llave primaria debe ser pblica, implementar
a la interface Serializable y tener un constructor sin argumento.
Ejemplo:
Dada la siguiente tabla tbmatricula con una llave primaria compuesta.
CIBERTEC
33
La Entidad y la clase Java que maneja la llave primaria pueden representarse as (no
olvidar que se debe generar los mtodos getter/setter en ambas clases Java):
Observe que la anotacin @IdClass especifica el nombre de la clase Java que maneja
la llave primaria.
CIBERTEC
34
Observe, tambin, que la clase Java que maneja la llave primaria no posee
anotaciones. Sin embargo, debe implementar los mtodos nombrados lneas arriba:
El mtodo equals () lo que hace es comparar uno a uno los atributos de la llave
primaria contra los atributos de otra entidad para verificar que no se trate de la misma
entidad.
El mtodo hashCode () lo que hace es devolver un cdigo hash de los valores de la
llave primaria.
Para consultar una entidad con una llave primaria compuesta, solo se requiere generar
una instancia de la clase que maneja la llave primaria, cargarle los valores necesarios
y pasar dicha variable al EntityManager.
Ejemplo:
CIBERTEC
35
1.2.5. Objetos Embebidos

Un objeto embebido es aquel que es dependiente de una entidad: no tiene identidad
por s mismo. Entender este concepto es muy til para el manejo de relaciones entre
entidades.
Si bien, a nivel de Java, los objetos embebidos se administran de forma separada, a
nivel de base de datos, la entidad y la clase embebida se almacenan sobre el mismo
registro de la tabla.
Por ejemplo, en el siguiente grfico, se tiene la entidad CUSTOMER y la tabla
tbcustomer. Observe que los datos de la direccin pueden constituir una clase
separada:
Si se convierte la direccin en una clase Embebida, quedara as:
CIBERTEC
36
Anotacin
@Embeddable
Anotacin
@Embedded
Se debe observar que:

a) La Entidad declara un atributo con el tipo de dato de la clase Address y a este
atributo le coloca la anotacin @Embedded para indicar que esa clase es
embebida.
b) La clase Address NO tiene anotaciones que indiquen que es una entidad.
nicamente tiene la anotacin @Embeddable para indicar que hay otra
clase que la incluye (o que la referencia).
c) Ambas clases tienen sus getter/setter.
d) Ambas clases deben definirse en el archivo persistente.xml.
e) Finalmente, es importante saber que solo se puede ejecutar series sobre la
clase marcada como Entidad.
CIBERTEC
37
Resumen
1. Una clase Java se convierte en Entidad al agregar la anotacin @Entity. Adems,
existen otras anotaciones que permiten el mapeo contra columnas de la tabla en
la base de datos.
2.
Existen cuatro maneras de generar la secuencias para IDs:

AUTO
TABLE
SEQUENCE
IDENTITY
3. Recordar el uso de la anotacin @Temporal para tipos de datos que manejan

tiempo.
unidad:
CIBERTEC
Anotaciones: http://www.objectdb.com/api/java/jpa/annotations/orm
38
1.3. RELACIONES ENTRE ENTIDADES

1.3.1. Conceptos bsicos
Roles
Las relaciones entre entidades tienen tres diferentes perspectivas:
a) La primera es el punto de vista desde un lado de la relacin.
b) La segunda en el punto de vista desde el otro lado de la relacin.
c) La tercera es la perspectiva global que mira ambos lados de la relacin.
Estos lados son conocidos como roles. Tal es as que en cada relacin hay dos
entidades que se relacionan mutuamente de tal manera que cada una cumple un rol
dentro de la relacin. Es ms, una entidad puede jugar muchos roles dentro de un
modelo.
Direccionalidad
Existen maneras de crear, remover y actualizar las relaciones para darles
mantenimiento. Si una entidad tiene relacin con otra, existir un atributo que sirve
para identificar la relacin y referirse a la entidad relacionada identificando as el rol
que juega en la relacin.
Cuando las entidades se referencian mutuamente se dice que la relacin es bidireccional. Ejemplo: El empleado sabe en qu Proyecto trabaja y el Proyecto conoce
quines son sus miembros (las flechas indican el sentido de la direccin).
Si una entidad apunta nicamente a otra, la relacin es unidireccional. El empleado

conoce su Direccin, pero la inversa no necesariamente es cierta (la flecha indica el
sentido de la relacin).
Ahora bien, la relacin Bi-direccional puede ser descompuesta en dos relaciones unidireccionales. Cada relacin tendr un origen (source o rol de referencia) y un
destino (target o rol referido). Se debe tener en cuenta esto, pues el origen y destino
varan segn la perspectiva que estemos usando para analizar la relacin.
Cardinalidad
CIBERTEC
39
La cardinalidad de una relacin sirve para determinar cuntas instancias de una

entidad existen en cada lado de una misma relacin.
Cada rol dentro de la relacin tendr su propia cardinalidad, la cual indicar cuando
exista una sola o muchas instancias.
Por ejemplo, muchos empleados pueden trabajar en el mismo departamento (se
muestra una relacin de muchos a uno):
Ordinalidad
Un rol puede especificarse de forma ms detallada para indicar si puede o no estar
presente en una relacin. La ordinalidad sirve para indicar si la entidad target
necesita ser especificada cuando la entidad source es creada.
Debido a que la ordinalidad es un valor lgico (verdadero o falso) es ms prctico
referirse a ella como opcionalidad de la relacin.
Mapeo de Relaciones
Existen bsicamente dos formas de asociacin:
Las basadas en valores simples.
Las basadas en colecciones de valores.
Dentro de esas formas de asociacin, existen cuatro formas de mapeo:
Relacin One-To-One (valores simples)
Relacin Many-To-One (valores simples)
Relacin One-To-Many (colecciones de valores)
Relacin Many-To-Many (colecciones de valores)
A nivel de Base de Datos, la relacin entre entidades significa que una tabla referencia
a otra tabla: aparece el concepto de Foreign Key para indicar aquellos campos de
una tabla que hacen referencia a la Primary Key de otra tabla.
A nivel de JPA las columnas que forman la Foreign Key se conocen como Join
Columns y emplean la anotacin @JoinColumn para indicar dicha funcionalidad.
CIBERTEC
40
1.3.2. Relacin Many To One

Es la relacin ms tpica que podemos encontrar en el mundo real.
En UML se requiere que la clase source tenga un atributo del tipo de la clasetarget
para poder navegar hacia ella.
Ejemplo: Si varios Empleados pueden trabajar en un Departamento, la relacin de
entidades se puede modelar como se muestra a continuacin:
Tenga en cuenta que:

a) La clase source tienen un atributo que corresponde al tipo de la clase target
(observe el atributo departamento).
b) A dicho atributo se le debe colocar la anotacin @ManyToOne.
Ahora falta llevar la relacin al modelo de base de datos siguiente:
CIBERTEC
41
Las tablas fsicas estn relacionadas mediante la columna DPTO_ID en la tabla

tbempleado que apunta a la columna DEPT_ID en la tabla tbdepartamento.
Entonces, la Join Column de la relacin es la columna DPTO_ID.
El lado que tiene a la Join Column se conoce como el OWNER SIDE de la relacin,
mientras que el lado que no tiene a la Join Column se conoce como INVERSE
SIDE.
En este ejemplo, el lado OWNER es la tabla tbempleado y el lado INVERSO es la
tabla tbdepartamento.
La anotacin @JoinColumn siempre se debe colocar en el lado OWNER de la
relacin.
La entidad Employee debe quedar as (observe la anotacin @JoinColumn):
CIBERTEC
42
Si no se coloca la anotacin @JoinColumn, JPA asume el nombre por defecto, el cual

est formado por el nombre del atributo en la entidad owner seguido de un guin bajo
(_) y concatenado con el nombre de la columna PK en la tabla inversa.
1.3.3. Relacin One to One

La relacin Uno a Uno es casi igual a la relacin Muchos a Uno con la sola
excepcin que una instancia de la entidad source puede apuntar a una nica
instancia de la entidad target. Estrictamente hablando, eso significa que la entidad
target no puede ser compartida por otras instancias de la entidad source.
A nivel de base de datos esta relacin implica un criterio de unicidad o llave nica en
la Foreign Key de la entidad source.
Obviamente se requiere definir la relacin en la Entidad Employee: para ello se hace

uso de la anotacin @OneToOne y tambin se requiere usar @JoinColumn (en este
caso, la columna de Join es PARKING_ID). La entidad Employee quedar as:
CIBERTEC
43
1.3.4. Bidireccionalidad de la relacin One-To-One
En algunas situaciones se requiere considerar la relacin inversa entre las entidades,

tambin conocida como bidireccionalidad de la relacin. La decisin es un criterio de
modelamiento, ms no una obligacin a nivel de programacin.
Para lograr esto, se requiere que la entidad target tenga un atributo de la clase
correspondiente a la entidad source. Dicho atributo debe tener la anotacin
@OneToOne con el elemento mappedBy que indique cual es el atributo de la clase
source que contiene la relacin y apunta a la entidad target.
Ejemplo: en el caso de la entidad ParkingSpace (es el target de la relacin) se
tendra el siguiente atributo:
Y en el caso de la entidad Employee (que es el owner de la relacin) tendramos:
CIBERTEC
44
Debe tenerse en cuenta dos reglas:

a) La anotacin @JoinColumn se coloca en la entidad que mapea a la tabla que
contiene la columna de join (o a la entidad que es owner de la relacin).
b) El elemento mappedBy debe colocarse a la anotacin @OneToOne de la
entidad inversa o target de la relacin.
1.3.5. Relacin One To Many
Cuando una entidad se asocia con una coleccin de otras entidades estamos ante
una relacin de uno a muchos.
En el ejemplo del Empleado vs. El Departamento, la relacin es bidireccional por
naturaleza. En una relacin bidireccional, siempre existen dos mapeos: uno por cada
relacin.
A nivel de base de datos, las tablas siguen siendo las mismas.
Y a nivel de entidades, la entidad Employee es la misma.

Como se tiene que implementar el lado inverso de la relacin entre Empleado y
Departamento, se debe modificar la entidad Department para agregar la relacin
inversa One-To-Many: se debe mapear una coleccin de entidades Empleado
usando la anotacin @OneToMany.
Adicionalmente, como este es el lado inverso de la relacin, se debe usar el atributo
mappedBy para indicar cul es el atributo dentro de la entidad Employee que
contiene la llave de la relacin:
CIBERTEC
45
NOTA: En este caso se est usando una coleccin indicado el tipo de los elementos
que almacena dicha coleccin: Collection<Type>. Esto genera una dependencia al
compilar por lo que no es recomendable.
La otra forma de colocar la relacin es especificando el atributo targetEntity sin

especificar el tipo de dato contenido en la coleccin:
Esquemticamente las dos relaciones se ven as:
CIBERTEC
46
Es importante tener en cuenta que:

a) El lado many-to-one siempre es el lado owner de la relacin. En
consecuencia, la anotacin @JoinColumn debe estar en dicho lado.
b) El lado one-to-many es el lado inverso, por lo que el elemento mappedBy
debe ser utilizado en este lado.
c) Si no se especifica el mappedBy, JPA considera que es una relacin
unidireccional de tipo one-to-many por lo que requiere el uso de una tabla de
Join. Tener en cuenta que esto puede ocasionar errores al desarrollar
aplicaciones.
1.3.6. Relacin Many To Many

Cuando una o ms entidades se asocian con una coleccin de otras entidades y
dichas entidades tienen relaciones sobrepuestas con las mismas entidades target, se
dice que estamos frente a una relacin de tipo Mucho-a-Muchos.
Por ejemplo: Un Empleado pueden trabajar en mltiples Proyectos y cada
Proyecto puede tener a muchos Empleados.
De los ejemplos anteriores podemos manejar las siguientes entidades:
CIBERTEC
47
La relacin Muchos-a-Muchos se puede expresar en las dos entidades (source y

target) utilizando la anotacin @ManyToMany. Teniendo en cuenta que:
a) Cuando la relacin Many-To-Many es bidireccional, ambos lados de la
relacin deben tener la anotacin @ManyToMany.
b) No existen columnas de join en cada lado de la relacin: la nica forma de
implementar esta relacin es utilizando una tabla de join, por lo que no existe
manera de determinar CUAL es el lado owner de la relacin, en
consecuencia, se debe asumir que uno de los lados es el owner.
c) Al igual que en las relaciones bidireccionales anteriormente tratadas, el lado
que no sea owner debe utilizar el mappedBy, en caso se omita este
elemento, JPA deducir que se trata de dos relaciones unidireccionales
separadas.
En el ejemplo, la anotacin @ManyToMany debe colocarse en ambas entidades:
CIBERTEC
48
El modelo de base de datos es:
A nivel de base de datos, una Join Table consiste simplemente de dos Foreign Key
o columnas de join que referencian (cada una) a un lado de la relacin.
La anotacin @JoinTable se usa para configurar la tabla de join de la relacin:
a) Cada columna de Join se distingue dependiendo del papel dentro de la
relacin: lado owner o lado inverso.
b) La columna de Join que pertenece al lado owner se describe usando el
elemento joinColumns.
c) La columna de Join que pertenece al lado inverse se describe usando el
elemento inverseJoinColumns.
En el ejemplo, falta indicar la JoinTable de la siguiente forma (asumiendo que

Employee es el owner de la relacin).
Tenga en cuenta que el elemento name dentro de @JoinColumn especifica el

nombre de la columna en la tabla de Join, mientras que el elemento
CIBERTEC
49
referencedColumnName indica la columna que es Primary Key en la tabla que se

encuentra al extremo de la relacin (sea owner o inversa).
Y en el lado inverso de la relacin se pone el elemento mappedBy:
1.3.7. Opciones de Fetch

Las entidades y sus atributos pueden ser cargados de dos formas:
LAZY: Cuando se cargan de forma perezosa, es decir, se cargan en el

momento en que se requieren.
EAGER: Cuando se cargan de forma proactiva, es decir, al momento de

cargar la entidad owner de la relacin.
En trminos de JPA, se usa el elemento fetch acompaando a la anotacin de la

relacin e indicando el valor de FetchType.LAZY o FetchType.EAGER.
En una relacin de valores simples el FetchType por defecto es EAGER.
En una relacin de colecciones de valores, el FetchType por defecto es LAZY.
En una relacin bidireccional, el FetchType puede ser EAGER en un sentido y LAZY
en el otro dependiendo del tipo de navegacin que se desea.
CIBERTEC
50
Resumen
1. Recordar que en JPA, existen cuatro tipos de relaciones entre entidades:
One To One
One To Many
Many To One
Many To Many
unidad:
JPA: http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa2.html
CIBERTEC
51
1.4. THE JAVA PERSISTENCE QUERY LANGUAGE

JPA soporta dos formas para expresar consultas que recuperan entidades desde una
base de datos:
El lenguaje de consultas (queries), conocido como Java Persistence Query

language (JPQL), es un lenguaje independiente del manejador de base de
datos que trabaja con entidades en lugar de usar tablas.
La API de criterios, que sirve para construir consultas basadas en objetos Java
en lugar de escribir los queries en strings.
1.4.1. Introduccin a JPQL

Los antecedentes de JPQL se pueden encontrar en la especificacin de EJB 2.0 con el
lenguaje EJB-QL en el cual se introdujo una forma de navegar entre los Beans y sus
relaciones, as como filtros y funciones agregadas.
Los queries operan dentro de una unidad de persistencia y pertenecen a una de las
siguientes clasificaciones:
a) SELECT, son queries que recuperan una o ms entidades, filtrando los
resultados si fuera necesario.
b) AGGREGATE, los queries de este tipo son variaciones de los queries del tipo
SELECT, con la salvedad que agrupan resultados para producir informacin
sumarizada (de ah la necesidad de usar la clusula GROUP BY).
c) UPDATE, son queries que se emplean para actualizar un conjunto de

entidades.
CIBERTEC
52
d) DELETE, son queries que se utilizan para remover un conjunto de entidades.
Al utilizar los queries se debe considerar que las entidades son referenciadas por su
nombre. Si una entidad no tiene asignado un nombre de forma explcita, JPA asume el
nombre de la clase como nombre por defecto: este nombre se conoce como abstract
schema name de la entidad dentro del contexto del query.
Tambin, es importante resaltar que para los queries es indiferente el uso de
maysculas y minsculas salvo en dos casos: nombre de entidades y nombres de
atributos de cada entidad.
Dada una entidad como la siguiente (entidad Employee):
El query ms sencillo que se pueden ejecutar es el siguiente:
Observe que la notacin es muy similar al SQL normal, pero con ligeras diferencias:
CIBERTEC
53
a) En JPQL, lo que sigue a la clusula FROM es el nombre de la entidad, es

decir, no se coloca el nombre de la tabla (recordar que la Entidad mapea a
una tabla).
b) En JPQL, es obligatorio que las entidades sean calificadas con un alias: en
el caso del ejemplo, el alias es e. Este alias se conoce como variable de
identificacin.
c) El alias indicar que el resultado ser uno o ms entidades del tipo
correspondiente a la entidad.
d) El tipo de resultado de un Query no puede ser una Coleccin. Debe ser un tipo
simple o una Entidad.
A partir del uso del alias para la entidad, se puede utilizar la notacin dot (el punto
.) para referenciar campos persistentes de la entidad. Por ejemplo, si queremos
seleccionar nicamente los nombres de los empleados sera as:
En este caso, como el campo nombre es un String, el resultado del query devolver
uno o ms Strings. De la misma forma puede trabajarse para cualquier otro atributo,
sea una lista, coleccin o campos simples.
El seleccionar algunos campos de la entidad (al igual que en SQL) recibe el nombre de
proyeccin. Se debe tener en cuenta su uso si es que se van a descartar (no usar)
varios atributos de la entidad al momento de generar reportes (dada la sobrecarga que
se genera en el framework JPA).
En el siguiente ejemplo, se puede seleccionar una entidad que no est en la clusula
FROM:
Observe que departamento es una campo de la entidad Employee, pero a la vez es

una Entidad (dada la relacin establecida @ManyToOne). Por tanto, el resultado de
ese query ser una entidad Department obtenida a partir de la relacin.
FILTROS
Al igual que en SQL, se puede filtrar los resultados a obtener utilizando la clusula
WHERE y la notacin dot.
JPQL incluye operadores como IN, LIKE y BETWEEN, funciones como SUBSTRING y
LENGTH adems de soportar subqueries.
Ejemplo:
CIBERTEC
54
En este ejemplo, el filtro lo constituye el atributo nombre de la entidad Department

que est vinculada con la entidad Employee.
JOIN ENTRE ENTIDADES

Al igual que en SQL, si se desea navegar entre las relaciones de las entidades y
retornar elementos de la coleccin, se debe ejecutar un JOIN entre entidades.
Se puede ejecutar el JOIN al ms puro estilo del tradicional SQL indicando los criterios
de JOIN en la clusula WHERE.
Sin embargo, JPQL proporciona la facilidad de especificar el JOIN dentro de la
clusula FROM con la finalidad de expresar el JOIN en trminos de la relacin
existente entre las entidades: JPA se encargar de armar la sentencia SQL
equivalente.
Un JOIN ocurre si se cumple cualquiera de las siguientes condiciones en el SELECT:
1) Dos o ms declaraciones de variables son listadas en la clusula FROM y
aparecen en la clusula SELECT.
2) El operador JOIN es empleado para extender a una variable de identificacin
usando expression path.
3) Un path expression en cualquier parte del query navega a travs de un campo
de asociacin en la misma o en otra entidad.
4) Una o ms condiciones WHERE comparan atributos de variables de
identificacin diferentes.
Se debe tener en cuenta que ante la ausencia de condiciones de JOIN entre
entidades, se generar un producto cartesiano entre la primera entidad y cada
ocurrencia de la segunda entidad.
INNER JOIN
Un inner join entre dos entidades se puede especificar de cualquiera de la maneras
indicadas anteriormente. Sin embargo, la forma preferida es mediante el uso del
operador JOIN en la clusula FROM.
La sintaxis bsica es:
[INNER] JOIN <path_expression> [AS] <identifier>
CIBERTEC
55
Ejemplo 1: se asume que phones contiene una relacin JPA entre Employee y
Phone
Ejemplo 2: mltiples Joins (los joins se interpretan de izquierda a derecha desde el

FROM)
OUTER JOIN
Un outter join entre dos entidades produce un mbito en el cual solo un lado de la
relacin es requerido para completar el resultado. Por ejemplo, un outer join entre
Empleado y Departamento mostrar todos los empleados y los departamentos a los
que han sido asignados, pero con la salvedad que el Departamento ser retornado
nicamente si existe dentro de la relacin (a diferencia de un inner join).
Su sintaxis es la siguiente:
LEFT [OUTER] JOIN <path_expression> [AS] <identifier>
Ejemplo 1:
FETCH JOIN
Este tipo de Join sirve para ayudar a los programadores a optimizar los accesos a la
base de datos. Permite que los queries especifiquen una o ms relaciones que deben
ser navegadas y pre-cargadas por el mecanismo de recuperacin de datos de tal
forma que no se ejecuten lazy load en tiempo de ejecucin. En otras palabras,
reduce la cantidad de accesos a la base de datos.
Ejemplo:
CIBERTEC
56
QUERIES AGREGADOS
La sintaxis es muy similar a SQL: se requiere el uso del agrupamiento con GROUP BY
Es opcional el uso del filtro mediante la clusula HAVING.
JPA incluye cinco funciones agregadas:
AVG: Promedio aritmtico.
COUNT: Cantidad de repeticiones.
MIN: Menor valor.
MAX: Mayor valor.
SUM: Suma de valores
Ejemplo:
En este ejemplo se obtienen todos los departamentos, la cantidad de empleados de

cada departamento, el sueldo mximo y el sueldo promedio teniendo en consideracin
solo aquellos departamentos que tengan ms de 5 empleados.
QUERIES
Existen dos formas para definir queries en JP-QL:
La primera forma es definirlo dinmicamente en tiempo de ejecucin como una

cadena de caracteres que se construye de acuerdo al flujo de la aplicacin.
Esto implica compilar el query cada vez.
La segunda forma es definir el query va anotacin o XML y referenciarlo por

el nombre cada vez que se requiera (algo similar a IBATIS). A diferencia de la
forma anterior, los queries nombrados son estticos, pero son mucho ms
eficientes para ser ejecutados.
1.4.2. Consultas dinmicas

Un query se puede definir de forma dinmica simplemente pasando una cadena de
caracteres con la sentencia JPQL al mtodo createQuery () del EntityManager.
Ahora bien, se puede indicar el resultado esperado o se puede omitir y de esta forma
tendremos un query sin tipo definido (unTyped query).
CIBERTEC
57
Para aquellas aplicaciones que utilizan muchos queries, se debe considerar el costo
de compilar la sentencia JPQL:
1) Se ejecuta un parse de la cadena JPQL en un rbol de sintaxis para verificar
que est correctamente escrito.
2) Para cada entidad dentro de la expresin se obtiene la metadata.
3) Se genera la sentencia SQL equivalente.
Se debe tener en consideracin (al igual que en JDBC) las implicancias de concatenar
un query y luego pasarlo al EntityManager para evitar la inyeccin de cdigo SQL
malicioso. Por ello es preferible usar parmetros. Tambin, para aquellos queries
empleados con mayor frecuencia, es preferible usar los queries nombrados
(NamedQueries).
Un ejemplo con TypeQuery:
TypedQuery
La sentencia JP-QL
Clase que retorna el query
La clase Order.java tiene un mtodo

toString()
Un ejemplo con Query:

La sentencia JP-QL
CIBERTEC
58
Query
La clase Order.java tiene un mtodo

toString()
1.4.3. Consultas nombradas

Este tipo de query sirve para organizar y mejorar el desempeo de una aplicacin.
Se define empleado la anotacin @NamedQuery, la cual se coloca dentro de la
definicin de una Entidad: la anotacin define no solamente el nombre del query sino
tambin la sentencia JPQL en s.
Se recomienda escribir los queries de manera ordenada de tal forma que ayuden a la
visibilidad y lectura de los mismos dentro de la definicin de la entidad.
El nombre del query (atributo name) debe ser nico dentro de toda la unidad de
persistencia. Si se hace caso omiso a esta restriccin, los resultados pueden ser
imprevisibles en tiempo de ejecucin.
Se puede definir mltiples queries nombrados empleando la anotacin
@NamedQueries, la cual es un arreglo que acepta varias anotaciones
@NamedQuery.
Ejemplo: El mismo query del ejemplo anterior, pero ahora definido en la clase
Order.java
Nombre del Query
Query JPQL
Se invoca as:
Se especifica que es NamedQuery
CIBERTEC
59
Se especifica el nombre del Query
Si deseamos definir varios NamedQueries en la entidad, se tendra que hacer as:
Anotacin
Query JPQL #1
Query JPQL #2
Y se puede invocar as:
Se especifica el nombre del Query
CIBERTEC
60
1.4.4. Uso de parmetros

Los parmetros enviados a un query permiten la reutilizacin de sentencias de forma
tal que las consultas ejecutadas con diferentes parmetros en cada invocacin,
retornen diferentes resultados. Es preferible enviar parmetros a las consultas en lugar
de estar construyendo una nueva cadena de caracteres por cada invocacin, pues as
se evita compilar repetidas veces los queries.
PARMETROS NOMBRADOS
Se utilizan cuando dentro de la sentencia JPQL, los parmetros van precedidos por el
smbolo de : seguido del nombre del parmetro.
Al momento de ejecutar el query, el programador debe especificar el nombre del
parmetro (empleando el mtodo setParameter) y el valor a ser cargado para
reemplazarlo dentro de la sentencia JPQL.
Los parmetros nombrados proporcionan claridad al cdigo de la sentencia JPQL
(cuando se utilizan nombres adecuados), por lo que son preferidos respecto a los
parmetros ordinales.
Ejemplo usando parmetros nombrados:
La sentencia JP-QL
Note el uso de named

parameters
Colocando los valores
PARMETROS ORDINALES
Se utilizan cuando dentro de la sentencia JPQL, los parmetros van precedidos por el
smbolo de ? seguido del nmero del parmetro.
Al momento de ejecutar el query, el programador debe especificar el nmero del
parmetro y el valor a ser cargado para reemplazarlo dentro de la sentencia JPQL.
Ejemplo con parmetros ordinales:
CIBERTEC
61
La sentencia JP-QL
Observe el uso de
parmetros ordinales
Se cargan los valores
1.4.5. Ejecucin de Queries

JPA proporciona tres formas de ejecutar queries:
a) Para queries que retornan un nico valor se aplica el mtodo getSingleResult
().
b) Para queries que retornan una lista de valores se aplica el mtodo
getResultList ().
c) Para queries que ejecutan sentencias de delete/update se aplica el mtodo
executeUpdate ().
Se debe tener presente que:
a) Por defecto, los queries devuelven listas desordenadas.
b) Cuando se aplica el mtodo getResultList (), el tipo de dato retornado es una
Collection (si no hay resultados, se devuelve una Collection vaca). Sin embargo, la
variable Java que recibe los resultados debe ser de tipo List. Ejemplo:
c) Cuando se aplica el mtodo getSingleResult (), si no existen resultados se

devuelve la excepcin NoResultException (la aplicacin deber controlar la
excepcin). La ocurrencia de esta excepcin no genera un rollback de la
transaccin en curso.
CIBERTEC
62
d) Cuando se aplica el mtodo getSingleResult (), si existen muchos resultados (en

lugar de uno)
se devuelve la excepcin NoUniqueResultException (la
aplicacin deber controlar la excepcin). La ocurrencia de esta excepcin no
genera un rollback de la transaccin en curso.
e) Cualquier query de tipo SELECT puede especificar adems el uso de modos de
bloqueo para los registros seleccionados con el fin de no impactar en la base de
datos los indicadores de rendimiento. Esto se ejecuta va el mtodo setLockMode
().
CIBERTEC
63
1.4.6. Sintaxis de JPQL
Trmino
Descripcin
entityName
Nombre de la Entidad. Por defecto es el nombre de la clase.
variable
Identificador que sigue las reglas de Java.
state_field_exp
Trmino utilizado para apuntar hacia un campo de la entidad.

Por ejemplo: Si Alumno est representado por la variable a,
se puede apuntar a los campos como: a.cdigo, a.nombre.
single_rel_exp
Trmino utilizado para apuntar hacia un campo de una entidad,

pero que resuelve relaciones de tipo one-to-one o many-toone.
se puede apuntar a los campos como: a.cursos, a.cursos.notas.
multi_rel_exp
Trmino utilizado para apuntar hacia un campo de una entidad,

pero que resuelve relaciones de tipo one-to-many o many-tomany.
se puede apuntar a los campos como: a.telfonos
rel_field
Trmino compuesto de una variable y una de los campos

relacionados sin navegar por relaciones intermedias.
se puede usar a.ciclo
constructor_method
Constructor para una clase que no es Entidad.
Input_param
Variable que representa a un parmetro de entrada y debe ser

asignado antes que el query sea ejecutado.
literal
Valor de un tipo particular (por ejemplo un string como hola o

un int como 99).
pattern_value
Un string que representa un valor SQL vlido.

Por ejemplo: %PEREZ
escape_char
CIBERTEC
Un carcter que representa una secuencia de escape.
64
CIBERTEC
CIBERTEC
65
66
CIBERTEC
67
Resumen
1. Diferenciar las clases Query y TypedQuery.
2. Recordar que el mtodo createQuery del EntityManager sirve para la creacin de
consultas dinmicas.
3. Recordar que el mtodo createNamedQuery del EntityManager sirve para la

creacin de consultas nombradas, las cuales se definen como anotacin
(utilizando @NamedQuery) dentro de la entidad respectiva.
4. Las anotaciones @NamedQuery y @NamedQueries se utilizan para definir
consultas nombradas.
5. El mtodo setParameter sirve para asignar un valor a un parmetro de una

sentencia JPQL. Existen dos formas: por parmetro nombrado y por parmetro
ordinal.
unidad:
CIBERTEC
JPQL: http://www.objectdb.com/java/jpa/query/parameter
68
CIBERTEC
69
UNIDAD
2
JAVA SERVER FACES 2
Al trmino de la unidad, el alumno, construye una aplicacin Web utilizando el
modelo MVC y toda la funcionalidad provista por el framework JSF (Java
Server Faces) en Primefaces en la capa Vista y JPA en la capa controlador
TEMARIO
2.1 Tema 5
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
:
:
:
:
:
:
:
:
Fundamentos de JSF
Introduccin a JSF
Arquitectura de JSF
Ciclo de vida de un request
Facelets
Managed Bean
Lenguaje de Expresiones JSF
Backing Beans
2.2 Tema 6 : Componentes de Interfaz de usuario

2.2.1 : Introduccin
2.2.2 : Arquitectura de Componentes UI
2.2.3
Librera Core
2.2.4
Librera HTML
2.2.5
Librera User Interface
2.2.6
Librera de Componentes Compuestos
2.3 Tema 7 : Conversiones, Validaciones y Eventos
2.3.1 : Introduccin
2.3.2 : El sistema de Conversin de JSF
2.3.3
El sistema de Validacin de JSF
2.3.4
El sistema de Mensajes de JSF
2.3.5
El modelo de Eventos de JSF
CIBERTEC
2.4 Tema 8
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
:
:
:
:
:
:
70
Integracin JSF y JPA

JSF y AJAX
Integracin JSF + JPA
Empleando otras implementaciones de JSF
Tablas JSF: Facets, dataTable y panelGrid
Mantenimiento de tablas
Implementar proyectos con la estructura JSF
CIBERTEC
CIBERTEC
71
72
2.1. FUNDAMENTOS DE JSF

2.1.1. Introduccin a JSF
Java Server Faces (JSF) es el estndar oficial en la capa web para la plataforma
Java EE. JSF incluye un conjunto de componentes predefinidos para la interfaz grfica
web (UI), un modelo de programacin basado en eventos y la habilidad para aadir
componentes desarrollados por terceros.
El objetivo de la tecnologa Java Server Faces (JSF) es construir aplicaciones web de
forma similar a cmo se construyen aplicaciones standalone con Java Swing, AWT
(Abstract Window Toolkit), SWT (Standard Widget Toolkit) o cualquier otra API similar.
JSF fue creado mediante el trabajo de la organizacin JCP (Java Community Process)
mediante la especificacin JSR 127 iniciada a mediados del ao 2001 y finalizada en
Marzo del 2004. Su principal objetivo es facilitar el desarrollo de interfaces grficas
para las aplicaciones web por medio de los siguientes caminos:
Proporciona un desarrollo basado en componentes, independientes del cliente.

De esta manera se incrementa la productividad del desarrollador.
Simplifica el acceso y administracin de los datos capturados o enviados a la

interfaz de usuario.
Maneja de forma automtica el estado de la interfaz de usuario entre mltiples

peticiones HTTP.
Proporciona un framework amigable mediante el uso de patrones de

arquitectura para las aplicaciones web.
En resumen, toma los mejores elementos de los frameworks que le precedieron (CGI,
Servlet, JSP, Struts, Spring MVC) y los combina en un conjunto de APIs estndares
para el desarrollo de interfaces de usuario.
La versin actual es JSF 2.0 y est soportada por las siguientes especificaciones:
JSR 127 : Java Server Faces ( http://www.jcp.org/en/jsr/detail?id=127 )
JSR 252: Java Server Faces 1.2 ( http://www.jcp.org/en/jsr/detail?id=252 )
JSR 276: Design-Time Metadata for

(http://www.jcp.org/en/jsr/detail?id=276 )
JSR 314: Java Server Faces 2.0 (http://www.jcp.org/en/jsr/detail?id=314 )
JavaServer
Faces
Components
Al ser JSF una especificacin, se pueden encontrar implementaciones de diferentes

fabricantes, lo cual permite no vincularse con ningn proveedor en particular y tener la
total libertad de seleccionar aquel que ms se acomode a nuestras necesidades.
Algunas implementaciones de JSF 2.0 son:
Proyecto Mojarra (La implementacin de referencia de SUN Microsystems
ahora propiedad de Oracle Corp.). Se puede consultar en el siguiente enlace:
https://javaserverfaces.dev.java.net/
CIBERTEC
73
Oracle ADF Faces, que extiende la funcionalidad de JSF proporcionando

muchas funcionalidades Ajax.
MyFaces (Fundacin Apache http://myfaces.apache.org/ ).
Rich Faces, alojado por Jboss (Grupo RedHat) en el siguiente enlace:
http://jboss.org/richfaces .
ICE Faces, que contiene diversos componentes para interfaces de usuario ms
enriquecidas.
Se
puede
obtener
informacin
en
el
enlace:
http://www.icefaces.org/main/home/ .
jQuery4jsf que contiene componentes basados en el Framework JavaScript
jQuery. Es un proyecto alojado por Google Code en el siguiente enlace:
http://code.google.com/p/jquery4jsf/
2.1.2. Arquitectura de JSF
Los objetivos de diseo de JSF y la manera en que los cumple se aprecian en el

cuadro siguiente:
Objetivo de Diseo
Objetivo #1:
Crear
un
framework
estndar
de
componentes UI que pueda ser potenciado
por herramientas de desarrollo y que a su
vez permita crear UI de alta calidad y
manejar la incorporacin de dichas UIs a la
aplicacin.
Objetivo #2:
Definir un conjunto ligero de clases Java
para los componentes UI, el estado de los
componentes y el manejo de eventos.
Objetivo #3:
Proporcionar un conjunto comn de
componentes UI incluyendo los elementos
estndares para formularios HTML. Dichos
CIBERTEC
Forma de Implementacin
JSF proporciona una API basada en
componentes que se pueden usar para
ensamblar aplicaciones web.
Los componentes UI estndar proporcionados
por la especificacin, estn acompaados de
tag libraries de tipo core y html (con
funcionamiento muy similar a JSTL)
componentes deben poder servir para

definir nuevos componentes.
Objetivo #4:
Proporcionar un modelo de JavaBeans
para controlar los eventos en el lado cliente
y conectarlos a la aplicacin.
74
JSF proporciona un mecanismo de fcil empleo

mediante el cual los componentes UI en el lado
web estn dbilmente acoplados (mediante un
Lenguaje de expresiones similar a JSTL) a los
POJOs del servidor ( conocidos como
Managed beans )
Los managed Beans se declaran en el archivo
faces-config, xml o se usan anotaciones.
Objetivo #5:
Definir APIs para validacin de datos de
entrada.
Objetivo #6:
Especificar un modelo para el manejo de
i18N en los componentes UI.
Objetivo #7:
Proporcionar una generacin automtica
del formato apropiado de salida hacia un
cliente determinado.
Objetivo #8:
Soportar accesibilidad
El control de la conversacin se realiza en el

JSF request process Lifecycle.
El JSF request process lifecycle tambin
permite manejar las validaciones y conversiones
dependiendo de los eventos que ocurren en la
aplicacin.
JSF
permite
construir
validaciones
personalizadas.
JSF proporciona el manejo de resource
bundles as como de localizacin (L10N). Los
componentes UI automticamente reconocen
estas caractersticas una vez que el bundle ha
sido configurado.
JSF proporciona APIs bastante flexibles
basadas en tecnologas de rendering que
pueden ser enchufadas bajo demanda. Por
ejemplo, si el cliente es un iPhone el render de
la pgina ser HTML especfico para dicho
equipo.
JSF confa plenamente en las tecnologas existentes de Java EE. Eso significa que
una aplicacin JSF es bsicamente una aplicacin desarrollada bajo los estndares
Java EE con algunas configuraciones especficas:
Configuracin #1: Dentro del deployment descriptor (archivo web.xml) de la
aplicacin, se debe registrar el servlet controlador (llamado Faces Controller). Tener
en cuenta que en algunos contenedores web como GlassFish v3 no se requiere el
archivo web.xml.
CIBERTEC
75
En caso que el archivo web.xml no exista o no se encuentre, el Faces Controller

mapea los urls siguientes de forma automtica:
/faces/*
*.jsf
*.faces
Tambin se puede agregar los siguientes mappings en el web.xml:
Configuracin #2: Opcionalmente se puede tener un archivo de configuracin de JSF

llamado faces.config.xml el cual est ubicado al mismo nivel que el web.xml
El archivo contiene la configuracin de todos los elementos de una aplicacin JSF,

aunque tambin pueden emplearse anotaciones en el cdigo java para evitar el uso
de este archivo. Un ejemplo del contenido del archivo faces-config.xml es:
CIBERTEC
76
Estas reglas se
conocen como JSF
Navigation Model
Configuracin #3: Si se est ejecutando la aplicacin en un contenedor web que no

soporta a JSF, las libreras del framework deben colocarse en el folder lib de la
aplicacin:
La construccin de pginas se realiza con Facelets XHTML empleando para ello tag
libraries. Se puede declarar las libreras usando XML namespaces o usando la
forma tradicional:
CIBERTEC
77
En resumen, una aplicacin JSF es como cualquier aplicacin web que incluye los
siguientes elementos:
Las pginas web.
Las libreras de etiquetas (o tags) para insertar componentes UI a las pginas.
Un conjunto de backed beans, que son componentes que definen las
propiedades y funcionalidad de los componentes de UI.
Archivos de configuracin para el modelo navigacional (aunque es opcional).
El indispensable archivo descriptor web.xml
Archivos desarrollados por los programadores: convertidores, validadores,
listeners.
Opcionalmente algunas etiquetas personalizadas para objetos UI
personalizados.
2.1.3. Ciclo de vida de un request

El ciclo de vida de una peticin JSF es la secuencia de eventos que suceden cuando
se hacen peticiones HTTP con una aplicacin JSF (la interaccin entre el navegador
web y la aplicacin).
La primera vez que se ejecuta la peticin, JSF crea un rbol de componentes UI en
memoria. Para las siguientes peticiones el rbol es rpidamente construido de nuevo:
si se capturan valores en un formulario, estos son procesados y validados.
Si la validacin es correcta, los valores capturados son cargados al modelo.
Luego, se procesan los eventos y se reportan los errores que pudieran ocurrir.
Si todos los eventos han sido procesados y el modelo ha sido actualizado
correctamente, se enva una respuesta final (render) al cliente. El manejo del ciclo de
vida de manera automtica lleva un control de los cambios en los estados de tal forma
que el cliente siempre refleje los cambios en el lado servidor.
El ciclo completo se muestra en el grfico:
CIBERTEC
78
Una explicacin detallada del ciclo:

FASE 1: Restore View
El concepto de Faces View es la representacin en el lado servidor3 (a manera de
espejo) de la interfaz de usuario que se muestra en el navegador.
En esta fase, se restaura una vista existente de alguna transaccin anterior o se
genera una nueva en funcin a la peticin HTTP entrante.
Si la peticin es nueva, se genera una vista que se almacena en un objeto conocido
como Faces Context, el cual sirve como almacenamiento para los datos de la
peticin http durante el manejo del ciclo de vida.
La vista generada sigue una estructura de rbol como la siguiente4:
FASE 2: Apply Request Values

En esta fase, se ejecuta todo el trabajo de procesar los pares de datos (conocidos
como value-pair parameters) que llegan en el request desde la pgina mostrada en el
lado cliente: el parmetro y su valor.
De esta manera, cada elemento del rbol que representa a la Faces View se carga
con el valor respectivo como se muestra en el grfico5:
A diferencia de una estructura de rbol DOM que se forma en el navegador, en el caso de la Faces
View, se genera en el lado del servidor.
4
Grfico tomado de Java Server Faces 2.0: The Complete Reference, pg 40.
Grfico tomado de Java Server Faces 2.0: The Complete Reference, pg 41.
CIBERTEC
79
Se debe especificar que existen dos tipos de componentes UI:
Aquellos que pueden aceptar valores: campos de texto, cajas de chequeo, etc.
Aquellos que permiten ejecutar acciones: botones y enlaces.
Es bueno saber que se puede alterar el curso normal de las fases para casos
especiales. Para ello se debe configurar el atributo immediate en un componente UI.
Tambin es bueno especificar que existen 3 tipos de interfaces usadas:
ValueHolder : implementada por todos los componentes UI que tienen el

atributo value
EditableValueHolder: implementada por todos los componentes UI de un

formulario, que poseen valores editables.
ActionSource: implementada por los componentes que generan acciones.
FASE 3: Process Validations

En esta fase se ejecuta la conversin y validacin de los datos recibidos. JSF invoca
al mtodo processValidators () en la instancia raz de UIViewRoot el cual se propaga
recursivamente hacia los componentes UI del rbol.
Cuando cada mtodo processValidators () de cada componente es invocado, se
ejecutan las conversiones y/o validaciones especificadas.
CIBERTEC
80
Si ocurre algn error de conversin o validacin, la propiedad valid se marca en

false y se encola un objeto FacesMessage en el FacesContext. Estos objetos sern
mostrados posteriormente en la vista del lado cliente.
FASE 4: Update Model Values

En esta fase, los datos se promueven hacia un objeto Java conocido como Managed
Bean.
El mecanismo es similar a las fases anteriores: en la instancia UIViewRoot se ejecuta
el mtodo processUpdate () el cual se propaga en cascada. Solo los componentes
definidos como tipo UIInput pueden enviar datos a un objeto Managed Bean.
Al final la fase, todos los atributos del objeto managed bean tienen cargados los
valores de la Faces View como se muestra en el grfico6:
FASE 5: Invoke Application

Es en esta fase en la que cualquier cdigo personalizado se puede ejecutar.
FASE 6 Render Response
En esta fase se ejecutan mtodos encodeXXX () para enviar el componente al
cliente. Los encode los que hacen es seleccionar el mejor tipo de lenguaje de marcas
apropiado para el cliente: HTML, WML, XML, etc.
Grfico tomado de: Java Server Faces 2.0: The Complete Reference, pg 43.
CIBERTEC
81
Adicionalmente, se graba el estado actual de la Faces View para que est disponible
en los subsiguientes requests.
Java Server Faces permite adems que se pueda codificar phase listeners para
controlar la ejecucin de cdigo en algn punto exacto del ciclo de vida del request.
Para ello se debe:
implementar la interface PhaseListerner.
registrar la clase en el archivo faces-config.xml o usar anotaciones.
2.1.4. Facelets
La tecnologa denominada Facelets View Declaration Language (VDL) fue
desarrollada como una extensin de JSF por Jacob Hookom e incorporada a la
especificacin JSF 2.0. El objetivo fue reemplazar el uso de JSP (aunque se mantiene
el reconocimiento de los JSP por motivos de compatibilidad).
Los Facelets permiten a los desarrolladores declarar componentes UI en diferentes
tecnologas de presentacin utilizando para ello plantillas (templates) HTML.
La meta de diseo principal fue permitir la composicin de una vista a partir de
diferentes pginas fsicas separadas7.
Algunos conceptos importantes en esta tecnologa:
a) Pgina (page): Se define as a la totalidad de la pgina web que es mostrada al
usuario. Se asocia con una viewId en el modelo de navegacin.
b) Fragmento de pgina (page fragment): se generan y utilizan como si fueran
pginas, siendo la principal diferencia que los fragmentos no son pginas web
completas sino que se emplean para armar pginas completas.
7
Patrn de diseo Composite View
CIBERTEC
82
c) Pgina de Plantilla (page template): son formatos reutilizables que se emplean

para construir pginas y/o fragmentos. Si existen porciones de pgina que son
comunes en muchas pginas web, se pueden crear plantillas para dichas
porciones.
d) Facet: son reas dentro de la pantilla en donde el contenido puede ser
agregado por los desarrolladores cuando generan las pginas. Los facets
pueden tener un contenido por defecto.
En la tecnologa JSP, los templates era codificados mediante el uso de:
jsp:incluye
<%@include
%>
En la tecnologa JSTL se utilizaba <c: import />

Las pginas en Facelets se generan usando XHTML. La idea de usar XHTML es
hacer portables a las pginas entre diversos ambientes de desarrollo.
Adems, Facelets requiere el uso de XML namespaces para soportar las siguientes
libreras de tags:
JSF HTML Tag Library.
JSF Core Tag Library.
JSTL Core Tag Library.
JSTL Functions Tag Library.
JSF Facelets Tag Library.
El encabezado de la pgina debe ser similar a esto (dependiendo de las libreras a
utilizar):
Las pginas en Facelets deben tener extensin .xhtml

En el archivo web.xml de la aplicacin debe configurarse los siguientes context
param:
CIBERTEC
83
El primer parmetro define que la extensin .xhtml es el sufijo por defecto de todas
las pginas que manejan contenido JSF.
El segundo parmetro indica que la implementacin de JSF ignore los comentarios
XML en las pginas Facelets.
Una comparativa8 entre JSP y Facelets:
Una gran caracterstica de los Facelets (no disponible en JSP) es el poder generar
templates. Un template es una pgina XHTML que emplea algunos tags de
Facelets para definir varias divisiones lgicas de la vista como por ejemplo:
cabecera, pie de pgina y contenido. La idea es tener partes reusables de cdigo sin
tener que repetir el mismo cdigo en diferentes pginas.
Tomada del Libro: Java Server Faces 2.0: The Complete Reference , pg 58
CIBERTEC
84
Existen dos perspectivas para desarrollar Templates9:
Template File: es el archivo conteniendo la plantilla o estructura de

composicin (formato) a generar. El contenido de este archivo est compuesto
por:
a. El contenido que debe ser mostrado a todos los clientes se escribe
directamente en el archivo.
b. El contenido que se puede reemplazar en cada archivo cliente se marca
con el tag <ui: insert>.
c. El template nunca debe ser accedido directamente por los clientes.
Template Cliente file: es el archivo que corresponde con una viewId. Emplea
una o ms pginas para generar el contenido basado en el Template File. Este
archivo contiene:
a. La especificacin del template file mediante el tag <ui:composition>
b. La especificacin del contenido a reemplazar con el tag <ui: define>
(que se asocia al tag <ui: insert> del template file).
Esquemticamente se puede ver as:
Muy similar a Apache Tiles
CIBERTEC
85
La tecnologa de Facelets proporciona tags en la librera denominada ui cuyo

namespace es http://java.sun.com/jsf/facelets :
Tag
ui:composition
ui:decorate
ui:define
ui:insert
ui:include
ui:param
ui:component
ui:fragment
ui:remove
ui:debug
CIBERTEC
Descripcin
Se usa en archivos que funcionan como
Template Client.
Este tag le dice a JSF que los tags
internos deben incorporarse a la jerarqua
de UIComponent
Especifica el template a emplear.
El texto que se encuentre fuera de los tags
<ui: composition> no se toma en cuenta
para el render de la pgina.
Se diferencia del anterior en que el
contenido dentro del tag es incluido en la
pgina antes que recortado (como en el
caso del ui:composition)
Es muy til cuando se tiene una serie de
elementos de una pgina que requieren la
misma apariencia.
Template Client.
Define una regin que ser insertada
dentro de la composicin (ui: composition).

Templates nicamente para indicar en
que parte del archivo se insertar el
correspondiente <ui: define> del template
cliente.
Al combinarse con <ui: param> permite la
inclusin personalizada de pginas.
Puede estar presente tanto en el
Template como en el Template Client.
Se usa exclusivamente dentro del <ui:
include> para definir parejas de valores
(nombre
y
valor)
disponibles
va
expresiones EL.
TAGS QUE NO SON PARTE DE LOS TEMPLATES
Sirve para asociar tags del cdigo a un
determinado UIComponent dentro del
rbol.
Similar a ui: component con la diferencia
que enmascara una serie de componentes
dentro de un componente padre antes de
incluirlo en el rbol de la vista.
Se emplea para comentar un fragmento
de los tags y evitar que se muestren en la
vista.
Permite que al presionar una tecla se
active una ventana mostrando el rbol de
componentes, las variables activas y cierta
86
informacin para depurar la aplicacin.

Se debe configurar context-param en el
web.xml con el valor:
javax.faces.FACELETS_DEVELOPMENT
Si no se especifica hockey, el valor por
defecto es CTRL-SHIFT-D
Ejemplo de Template:
Observe las primeras lneas de cdigo y anote las declaraciones en el tag

<html>: se declaran los namespaces de las libreras.
Observe los bloques con el tag <ui: insert>. Lo que est dentro del bloque es el
valor por defecto de esa zona (si es que el viewID no reemplazara nada).
Observe la lnea 9 para ver el uso de resources folders. En este caso, la
aplicacin busca un folder resources y dentro de este, busca el nombre de la
library que est como parmetro (css).
Los tags <ui: include> permiten incorporar contenido que se encuentra en otros
archivos, dentro del template o de la viewId.
CIBERTEC
87
Ejemplo de viewID o pgina cliente:
Observe las declaraciones del tag <html> en las primeras lneas.

En la lnea 10 se declara el <ui: composition> para indicar cul es el archivo de
layout con el que trabaja esta pgina.
Los bloques <ui: define> sirven para reemplazar el contenido de cada bloque
dentro de la zona de la plantilla identificada con el mismo nombre.
Tenga en cuenta que el contenido que se encuentre fuera de los tags <ui:
composition> no aparecer en los clientes.
CIBERTEC
88
Ejemplo de tag <ui: decorate>:
En este caso se mostrar tanto el texto anterior como posterior al tag.
CIBERTEC
89
2.1.5. Managed Bean

Al igual que el Framework Spring que proporciona la nocin de Inversin de Control
(IoC), JSF tambin proporciona una robusta habilidad para ello con las facilidades de
los Managed Beans.
Una Managed Bean es una clase Java que representa informacin de un formulario
web.
Para ello hace uso de los POJOs (Plain Old Java Objects), que son objetos que
almacenan datos de la aplicacin pero que no implementan o extienden ninguna
interfaz o clase especfica de algn Framework.
Un POJO declarado dentro de una aplicacin JSF se convierte en un Managed Bean
al cual nunca se le generar utilizando el mtodo new de una clase Java. En lugar
de ello, el contenedor JSF inicializar el objeto nicamente cuando la aplicacin lo
requiera (Lazy initialized).
Cualquier clase Java que siga las reglas de los Java Beans puede ser registrada como
una Managed Bean. Debe tenerse en cuenta que hay dos maneras de configurar los
managed bean:
Usando anotaciones dentro del programa Java. Es la forma ms recomendada

pues permite un cdigo ms cohesionado y fcil de mantener. Se emplea la
anotacin @ManagedBean antes de la definicin de la clase (desde JSF 2.0).
Usando XML dentro del archivo faces-config.xml. Se emplea el tag

<managed-bean> para efectuar la declaracin.
Un managed Bean tpicamente tiene 3 partes:

a) Las propiedades del Bean: generalmente un getter y un setter por cada
atributo. Los mtodos setter son invocados automticamente por el JSF
cuando el formulario web es enviado.
b) Mtodos para controlar acciones: Generalmente es solo un mtodo, pero
podran ser varios si es que el formulario posee mltiples botones de envo.
c) Un lugar para los datos resultantes: No es invocado automticamente por JSF.
Debe ser llenado por el mtodo controlador en base a los resultados de la
lgica de negocio.
Un ejemplo de una aplicacin sencilla JSF: Se presenta un formulario donde se debe
ingresar un nombre y presionar el botn de saludar. La aplicacin responde con una
pgina de saludo.
CIBERTEC
90
El Managed Bean es bastante sencillo:
CIBERTEC
91
Y la pgina de respuesta:
Como se ve en el ejemplo, el Managed Bean est marcado para funcionar en el

mbito @SessionScoped. Sin embargo, los mbitos pueden ser:
mbito
none
@NoneScoped
(slo JSF 2.0)
Descripcin
Puede referenciar
a otros managed
Beans del mbito
Los Managed Beans con ste none
mbito no se generan ni
almacenan en ningn mbito.
Ellos son generados bajo
demanda por otros Managed
Beans.
request
@RequestScoped
Su tiempo de vida depende del

Managed Bean que lo invoc.
Pueden ser generados y estn none, request,
disponibles durante
una view, session,
peticin HTTP simple.
application
Esto significa que el Bean
sobrevive a la navegacin hacia
CIBERTEC
view
@ViewScoped
(slo JSF 2.0)
session
@SessionScoped
application
@ApplicationScoped
Custom
@CustomScoped(value="#{so
meMap}")
92
otra pgina.
Permanecen
disponibles none,
view,
durante el tiempo que el usuario session,
permanezca en la misma vista.
application
Al salir de dicha vista, los
Managed
Beans
son
eliminados.
Se almacenan en la sesin
HTTP. Esto significa que los
valores de sus atributos son
almacenados a lo largo de
mltiples peticiones HTTP para
un usuario.
Retienen sus valores a lo largo
de la vida de una aplicacin, por
lo que estn disponibles para
TODOS los usuarios.
El bean se almacena en un
Mapa y el desarrollador tiene el
control del ciclo de vida del
mismo.
none, session,
application
none,
application
2.1.6. Lenguaje de Expresiones JSF

El lenguaje de expresiones utilizado en JSF 1.0 y 1.1 era una extensin del JSP
Standard Tag Library (JSTL). La principal extensin que se introdujo en EL con JSF y
que no est presente en versiones anteriores es el concepto de expresiones diferidas
(deferred expresiones).
En JSP, todas las expresiones que aparecen entre ${} se evalan

inmediatamente tan pronto como la pgina en renderizada.
JSF introduce el procesamiento del ciclo de vida del request que controla lo
que sucede cuando se ejecuta un submit. Para ello, se introduce el concepto
de expresin diferida para permitir que las expresiones sean utilizables tanto
durante el rendering de la pgina como durante el submit.
Este concepto permite que una expresin entre smbolos # {} como por
ejemplo # {usuario.nombre} sirva tanto para mostrar un valor al usuario como
tambin para recibir el valor ingresado por el usuario.
El objetivo de tener un Lenguaje Unificado de Expresiones (EL) es proporcionar una

manera fcil de acceder a los objetos desde cualquier punto de la aplicacin. En
general EL:
Evita la necesidad de referir al objeto padre (request, sesin o application).
Evita usar directamente los mtodos get/set del objeto.
Permite navegar de forma arbitraria en la jerarqua de objetos JavaBeans
(usando la notacin .dot).
Por ejemplo:
CIBERTEC
93
Esta expresin es una forma abreviada de invocar al mtodo getFirstName () de una

Managed Bean llamado userBean:
La primera parte (en este caso userBean) es la BASE que indica el mbito
donde buscar.
La segunda parte (en este caso firstName) es la propiedad, la cual puede
navegarse usando la notacin .dot.
Una facilidad que brinda E.L. es la invocacin directa a mtodos pblicos y no

estticos de los managed beans. Por ejemplo:
NOTA: Para que E.L. sea lo ms simple posible, no est permitido el envo de
parmetros a los mtodos.
JSF busca los objetos en un orden jerrquico comenzando por los objetos implcitos
para luego buscar en los managed beans de la aplicacin. El siguiente cuadro resume
los objetos implcitos que pueden constituir la BASE:
CIBERTEC
94
NOTA:
1) Las propiedades de los objetos que son de tipo Map se acceden usando:
# {MapObject [key]}
2) El objetoFlash es un tipo de almacenamiento temporal que permite que los
datos estn presentes en el siguiente request.
OPERADORES E.L.
Adems de los corchetes (para Map) y del punto (.) existen otros operadores como se
muestra en la tabla siguiente:
CIBERTEC
95
2.1.7. Backing Beans

Para implementar los backing beans en JSF, se debe crear una clase Java por cada
pgina JSF y registrar dicha clase como una managed bean. Lo usual es que la clase
Java se llame igual que la pgina.
Se recomienda que los backing beans se declaren en el mbito del request.
En general, los backing beans se encargarn de armar toda la tubera necesaria
entre la pgina y el modelo, porque:
Contienen las propiedades correspondientes a los campos de entrada del
formulario.
Contienen action methods y action listener que corresponden a los
componentes UI.
Contienen declaraciones de instancias de componentes UI que se vinculan a
los componentes UI utilizados en la pgina.
CIBERTEC
96
Resumen
1. JSF es una especificacin, por tanto tiene varias implementaciones de diversos
fabricantes.
2. Bsicamente tiene 4 libreras: core, html, user interface y composite que pueden
ser complementadas con libreras de otros fabricantes.
3. El lenguaje de expresiones requiere la sintaxis: # {} y permite la referencia a
propiedades de managed beans como tambin a mtodos.
4. JSF tiene dos formas de navegacin: la implcita y la explcita ( que requiere el
uso del archivo faces-config.xml )
5. JSF permite el empleo de plantillas mediante el uso de los tags d ela librera ui.
unidad:
o
o
Facelets:http://www.mkyong.com/jsf2/jsf-2-templating-with-facelets-example/
JSF: http://www.mkyong.com/jsf2/jsf-2-0-hello-world-example/
CIBERTEC
97
2.2. COMPONENTES DE INTERFAZ DE USUARIO

2.2.1. Introduccin
Los componentes UI Java Server Faces son elementos configurables y reutilizables
que componen la interfaz de usuario de las aplicaciones Java Server Faces.
Un componente se define como una pieza de software con reglas de uso bien
definidas que permitan que pueda ser utilizado por otros componentes.
Un componente de interfaz de usuario (UI Component) es un tipo especfico de
componente que muestra contenido que puede ser modificado por el usuario a lo largo
del tiempo. Este contenido puede ir desde un simple campo de ingreso de datos o
botones, hasta elementos ms complejos como rboles o datagrids.
La tecnologa Java Server Faces proporciona un conjunto de clases de componentes
UI, que especifican toda la funcionalidad del componente, cmo mantener su estado,
mantener una referencia a objetos del modelo, y dirigir el manejo de eventos y su
representacin para un conjunto de componentes estndar.
Estos componentes son completamente extensibles, lo que significa que podemos
extenderlas para crear nuestros propios componentes personalizados. Es ms, la
tecnologa JSF es tan flexible que proporciona una arquitectura de componentes que
incluye:
Un conjunto de clases UIComponent para especificar el estado y

comportamiento de componentes UI.
Un modelo de representacin (rendering) que define cmo representar los
componentes de diferentes formas.
Un modelo de conversin que define cmo conectar conversores de datos a un
componente.
Un modelo de validacin que define cmo registrar validadores con un
componente.
Un modelo de eventos (events) y oyentes (listeners) que define cmo
manejar los eventos de los componentes.
Todas las clases de componentes UI de Java Server Faces descienden de la clase

UIComponentBase, que define el estado y el comportamiento por defecto de un
UIComponent. Las clases auxiliares como Renderer, tag Handlers, Validador,
Converter, etc tcnicamente no son Componentes UI porque no colaboran en la
representacin visual del componente.
Los Componentes UI adems tienen un conjunto de archivos como imgenes, hojas
de estilo y JavaScripts que generalmente son responsables de la apariencia y
comportamiento de componente dentro de una pgina web. La especificacin JSF se
refiere a dichos archivos como recursos.
CIBERTEC
98
2.2.2. Arquitectura de Componentes UI

Los componentes UI se pueden clasificar en dos tipos:
Aquellos que inician una accin como por ejemplo los botones.
Aquellos que proporcionan datos como los campos de ingreso.
En JSF, los componentes se pueden ubicar en una de las dos clasificaciones
mencionadas en base a las interfaces que implementan segn la especificacin JSF
(para el primer caso es la interface ActionSource2 y para el segundo caso es la
interface ValueHolder o la interface EditableValueHolder). La razn para el uso de
interfaces es utilizar la ms alta abstraccin posible con el fin de encapsular las
capacidades de todos los componentes UI. De esta manera es mucho ms fcil
entender todos los componentes JSF simplemente comprendiendo las interfaces que
se implementan.
Se debe indicar que los componentes, adems de las interfaces mencionadas, pueden
implementar otras interfaces para definir un comportamiento particular.
El siguiente cuadro resume esta clasificacin:
CIBERTEC
99
Interfaz
Caractersticas de un componente que

implementa la interfaz
EditableValueHolder
Tiene un valor que puede ser

editado por el usuario y enviado al
servidor.
La edicin del valor puede
deshabilitarse temporalmente.
ActionSource2
Ocasiona la ejecucin de un
ActionEvent cuando el usuario
presiona
click
sobre
el
componente.
Tiene un estado que necesita Cada
componente
mantenerse
entre
peticiones UIComponent
y
cada
HTTP.
componente de ayuda (Helper
class )
Tiene un valor que no puede ser
UIOutput
editado por el usuario.
Es diferente al componente cuya
capacidad de edicin puede ser
deshabilitada.
Proporciona
un
mbito
de
UIForm
nombres para sus componentes
UINamingContainer
hijos.
UIData
PartialStateHolder
ValueHolder
NamingContainer
Algunos componentes ( y las

subclases ) que implementan la
interfaz
UIInput
UISelectBoolen
UISelectMany
UISelectOne
UIViewParameter
UICommand
ClientBehaviorHolder Soporta el comportamiento del Todos los componentes HTML

cliente como por ejemplo Ajax
estndares.
La jerarqua de clases de los componentes10 dentro del paquete

javax.faces.component es la siguiente (donde la flecha continua significa herencia y
la discontinua significa implementacin):
10
Fuente: Libro Java Server Faces 2.0: The Complete Reference, pg 140.
CIBERTEC
100
Si bien esta jerarqua encapsula al componente, no describe la forma en que dicho

componente ser mostrado al usuario.
Un ejemplo de algunos componentes UI:
UICommand: Representa un control que dispara actions cuando se activa.
UIForm: Encapsula un grupo de controles que envan datos de la aplicacin.
Este componente es similar a la etiqueta HTML <form>.
UIGraphic: Muestra una imagen.
UIInput: Toma datos de entrada del usuario. Esta clase es una subclase de
UIOutput.
UIOutput: Muestra la salida de datos en un pgina.
UIPanel: Muestra una tabla.
CIBERTEC
101
UISelectItem: Representa un solo tem de un conjunto de tems.

UISelectItems: Representa un conjunto completo de tems.
UISelectBoolean: Permite a un usuario seleccionar un valor booleano en un
control. Esta clase es una subclase de UIInput.
UISelectMany: Permite al usuario seleccionar varios tems de un grupo de
tems. Esta clase es una subclase de UIInput.
UISelectOne: Permite al usuario seleccionar un tem de un grupo de tems.
Esta clase es una subclase de UIInput.
Adems, JSF proporciona un conjunto de componentes UI para HTML que facilitan el

desarrollo de aplicaciones web especficamente para clientes HTML (navegadores).
Dicho conjunto de componentes reside en el paquete javax.faces.component.html y
derivan de la misma jerarqua de clases mostrada, con la caracterstica especfica de
trabajar para clientes HTML.
Normalmente, el desarrollador no trabajar con los componentes directamente sino
que aprovechar las caractersticas proporcionadas por el Renderer de JSF: un
Renderer es una clase responsable de tomar una instancia del UIComponent y
generar la salida a ser mostrada segn las caractersticas especficas del cliente.
Como se mencion en el tema del ciclo de vida de un request JSF, el rbol de
componentes UI (que se conoce como Vista) es manejado por el ViewHandler. Sin
embargo, el StateManager se encarga de preservar el rbol de componentes entre los
subsiguientes requests. Para ello, se guarda el estado completo de los componentes
utilizando un mecanismo especificado en el web.xml de la aplicacin:
Los parmetros a colocarse pueden ser:

server: significa que el estado de la aplicacin debe almacenarse en el servidor
entre cada request. Este es el comportamiento por defecto, por lo que no es
necesario colocarlo en el web.xml.
client: significa que el estado de la aplicacin se almacena en el cliente. Se
almacena como una marca dentro de la pgina de forma tal que aparezca
escondida y sea enviada como un campo oculto (tipo hidden).
La librera de componentes estndares est compuesta por cuatro libreras:
La librera CORE: se asocia al namespace f: y proporciona utilidades para

validacin, conversin, internacionalizacin, etc. La librera core no es
especfica para clientes HTML dado que ninguno de sus componentes tiene
una representacin visual en el lado cliente.
La librera HTML: se asocia al namespace h: y est diseada
especficamente para clientes HTML dado que proporciona un conjunto de
objetos comunes a muchas aplicaciones web: botones, campos de texto, etc.
La librera de tags para Plantillas FACELET: asociada al namespace ui:
permite agregar funcionalidades de plantillas y formatos. Fue introducida en
JSF 2.0.
CIBERTEC
102
La librera de tags para Componentes Compuestos: introducida tambin con

JSF 2.0, se registra bajo el namespace cc: y agrega la habilidad para definir
un contrato de uso con componentes compuestos.
2.2.3. Librera Core

El namespace con el que se declara es http://java.sun.com/jsf/core y se le asigna el
prefijo f.
Se listan las principales funcionalidades de cada tag. Para el detalle de los atributos
soportados, por favor consultar la documentacin de JSF.
Tag <f: actionListener>
Permite al desarrollador registrar de forma declarativa una instancia de ActionListener
sobre un Componente UI.
Un ActionListener es un manejador de evento que responde a eventos que suceden
en la pgina JSF.
Tag <f: ajax>

Permite al desarrollador agregar de forma declarativa, comportamiento Ajax al
componente asociado.
Tag <f: attribute>
Agrega un atributo con un nombre especfico y un valor string a un componente dentro
del tag si es que dicho componente no contiene un atributo con dicho nombre.
Los valores se almacenan en un Map que es parte del componente de tal forma que
los valores persisten cuando se administra el estado de dicho componente.
Tag <f: convertDateTime>

Se utiliza para convertir valores String a valores java.util.Date.
CIBERTEC
103
Tag <f: convertNumber>

Se utiliza para convertir valores String a valores java.lang.Number.
Este tag maneja una serie de patrones para formateo de los valores.
Tag <f: converter>
Este tag crea una instancia de la clase Java registrada con el ID especificado, la cual
debe implementar a la interfaz javax.faces.convert.Converter. Luego, asocia esta
instancia con el componente UI ms cercano.
Tag <f: event>

Permite
que
el
desarrollador
registre
de
manera
ComponentSystemEventListener en un componente UI.
declarativa
un
Soporta dos atributos:

listener: cuyo valor debe ser un Method Expression que se refiere a un
mtodo con la misma firma que el mtodo processEvent de la interfaz
ComponentSystemEventListener.
type: especifica el nombre del evento.
preRenderComponent
preRenderView
postAddToView
preValidate
postValidate
Ejemplo:
Tag <f: facet>

Representa un componente anidado que mantiene una relacin especial con el tag
que lo encierra.
Tag <f: loadBundle>
CIBERTEC
104
Este tag permite manejar el modelo de i18N especificando un recurso (bundle) para el
locale de la vista actual. El contenido del bunle es cargado en un Map.
Tag <f: metadata>

Este tag encapsula un conjunto de elementos que se utilizan para especificar la
metadata para una vista Facelet. En consecuencia debe ser un tag hijo del tag f: view.
En el siguiente ejemplo, se especifica que el valor del parmetro que viene en el
request HTTP con el nombre foo ser automticamente recuperado y cargado dentro
de la propiedad bean.foo.
Tag <f:param>
Se utiliza para sustituir parmetros cuando se emplea dentro de un tag
<h:outputFormat> o para agregar valores query-string a un URL cuando se utiliza
dentro de <h:commandLink> o <h:outputLink>
Tag <f: phaseListener>
Sirve para registrar una instancia de PhaseListener sobre el UIViewRoot en donde se
encuentra anidado el tag.
Tag <f: selectItem>
Agrega un componente hijo de tipo UISelectItem al componente UIComponent ms
cercano.
Ejemplo:
Tag <f: selectItems>

Este tag ubica al componente padre UIComponent ms cercano y crea un nuevo
UISelectItems vinculndolo a dicho componente padre.
CIBERTEC
105
Ejemplo 1: ColoresMap es un mapa (Map) a partir del cual se carga un listado de

colores.
Ejemplo 2: Ahora la lista de colores se toma desde una Collection.
Tag <f: setPropertyActionListener>

Este tag permite colocar un valor directamente en un atributo de un backing bean.
Ejemplo:
Tag <f: subview>

Sirve para crear una subvista. Es til con JSP pero no tiene mayor trascendencia en
facelets. Sirve como contenedor para todos los componentes UIComponents usados
dentro de una pgina anidada que se incluye va <jsp: include> o va JSTL con <c:
import>.
Ejemplo:
CIBERTEC
106
Tag <f: validateBean>

Este tag se integra al JSR 303 que especifica el Bean Validation API. El uso de este
tag causada que una instancia de javax.faces.validator.BeanValidator se registre en
el componente padre.
Ejemplo:
Tag <f: validateDoubleRange>

Sirve para generar validaciones sobre el componente padre. Soporta atributos de
mximo y mnimo.
Ejemplo:
Tag <f: validateLength>

Sirve para generar validaciones sobre Strings en el componente padre. Soporta
atributos de mximo y mnimo.
Ejemplo:
Tag <f: validateLongRange>

Sirve para generar validaciones sobre el componente padre. Soporta atributos de
mximo y mnimo.
Ejemplo:
Tag <f: validateRegex>

Este tag crea una instancia de javax.faces.RegularExpression y la asocia al
componente padre para efectuar las validaciones.
Ejemplo:
CIBERTEC
107
Tag <f: validateRequired>

Este tag genera una instancia de javax.faces.Required y lo asocia al componente
padre.
La funcionalidad es la misma que si se configura el atributo required en true para
un componente editable.
Ejemplo:
Tag <f: validator>

Genera un validador y lo asocia al componente padre.
Ejemplo:
Tag <f: valueChangeListener>

Registra un Listener asociado a la instancia del component padre.
Ejemplo:
Tag <f: verbatim>

Este component es til para JSP, pero no tiene mayor propsito con JSF Faceleters.
Crea y registra una instancia hija de UIOutput en el componente asociado ms
cercano.
Sirve para anidar contenido en HTML, XML o cualquier otro lenguaje de marcas.
Ejemplo:
CIBERTEC
108
Tag <f: view>

Sirve para crear una vista. La vista sirve como contenedor para todos los
componentes JSF utilizados en una pgina.
Tag <f: viewParam>

Permite que de forma declarative se registren parmetros como metadata asociada a
la vista padre por lo que debe ser un componente hijo del tag <f: metadata>. El
objetivo es soportar vistas favoritas que puedan ser invocadas va mtodo GET.
Ejemplo:
2.2.4. Librera HTML

El namespace con el que se declara es http://java.sun.com/jsf/html y se le asigna el
prefijo h.
Tag <h: body>

Es el tag encargado de mostrar los cdigos HTML <body> y </body> en una vista.
Tag <h: head>
Es el tag encargado de mostrar los cdigos HTML <head> y </head> en una vista. Se
utiliza para que JSF pueda incluir hojas de estilo y javascripts generados por los tags
<h: outputScript> y <h: outputStylesheet>
Tag <h: form>
CIBERTEC
109
Es el tag que muestra un formulario para captura de datos. Todos los tags que se
encuentren en el interior sern enviados con el formulario. Configura un atributo
action apuntando a un URL que define la accin a ejecutar y el atributo method
configurado en POST.
Tag <h: outputScript>

Este tag muestra el tag HTML <script> con el atributo src determinado por los
valores de name y library ingresados.
La especificacin de JSF 2.0 requiere que los recursos de la aplicacin web sean
colocados debajo del folder resources.
Tag <h: outputStyleSheet>

Este tag muestra el tag HTML <link> con el atributo href determinado por los valores
de name y library ingresados. Adems, muestra el atributo rel con los valores de
stylesheet y text/css.
CIBERTEC
110
Tag <h: inputText>

Muestra un campo de entrada de datos con el tag HTML <input> y el atributo type
configurado en text.
Tag <h: inputTextarea>

Muestra un campo de entrada de datos con mltiples lneas usando el tag HTML
<textarea>.
Tag <h: inputSecret>

Este tag muestra una caja de ingreso de datos del tipo password, es decir, los
valores no se muestran al usuario.
Tag <h: inputHidden>

Este tag genera un campo oculto dentro de la pgina. El componente no se visualiza
al momento del render en el cliente.
Tag <h: outputLabel>
Este componente muestra una etiqueta de texto usando el tag HTML <label> y puede
de manera opcional, ser especificada para un campo de ingreso (con el atributo for).
CIBERTEC
111
Tag <h: outputLink>

Este componente muestra un enlace usando el tag HTML <a> con el atributo href
configurado con el valor del componente.
Si se desea enviar parmetros en el link se puede usar la forma siguiente:
Tag <h: outputFormat>

Muestra un texto formateado. El texto se muestra dentro de un tag HTML <span> si es
que se indica el atributo id o algn atributo de estilo.
Tag <h: outputText>

Muestra el valor del componente como texto dentro de una pgina.
Tag <h: commandButton>

Este componente muestra un botn con el tag HTML <input> y el type configurado a
submit, reset o image.
Puede ser asociado a un backing bean o a un ActionListener para manejar eventos.
La etiqueta del botn se especifica con el atributo value o con el url de la imagen.
CIBERTEC
112
Adicionalmente, soporta la obtencin del texto desde un Bundle para efectos de

manejar i18N.
El tag emplea el mtodo POST para enviar la data al servidor.

El atributo type puede ser submit o reset.
El atributo action se asocia a un mtodo de algn backing bean.
Tag <h: button>

Este component es similar a <h: link> y fue introducido en JSF 2 para permitir el
soporte a vistas Facelets que puedan ser marcadas como favoritas (bookmarks).
Se presenta un problema si los navegadores tiene el javaScript deshabilitado debido a
que el tag genera un evento onclick para manejar la navegacin va
window.location.href.
Ejemplo:
Este cdigo genera el siguiente HTML:
Tag <h: message>

Este componente muestra los mensajes generados por JSF para el componente
identificado por el atributo for.
Tag <h: messages>
CIBERTEC
113
Muestra todos los mensajes almacenados.

Si el atributo globalOnly est en true, muestra los mensajes sin el identificador de
componente.
Utiliza celdas HTML de una tabla si es que se configura el atributo layout en table.
Tag <h: graphicImage>

Este componente sirve para mostrar una imagen utilizando el tag HTML <img> con el
valor del atributo src apuntando al valor del componente (value) o al atributo url.
En JSF 2 se agregan los atributos library y name para soportar imgenes desde
libreras de recursos.
Otra forma es usando el atributo url:
Tag <h: selectOneListBox>

Este componente muestra un <select> HTML cuyo tamao de lista es igual a la
cantidad de elementos <option>. Solo permite la seleccin de un elemento.
CIBERTEC
114
Tag <h: selectOneMenu>

Este componente muestra un <select> HTML cuyo atributo name es el ID del
componente y el atributo size es 1.
Cada opcin del men se muestra como un elemento <option>. Si la opcin se marca
como deshabilitada, se agrega el atributo disabled.
Tag <h: selectOneRadio>

Este component muestra una table HTML con un conjunto de radio buttons entre los
cuales el usuario puede escoger.
CIBERTEC
115
Tag <h: selectBooleanCheckbox>

Este componente muestra un elemento HTML <input> de tipo checkbox.
Tag <h: selectManyCheckbox>

Muestra una tabla con un conjunto de checkboxes.
Tag <h: selectManyListBox>

Muestra un tag HTML de tipo <select> pero permitiendo selecciones mltiples.
CIBERTEC
116
Tag <h: selectManyMenu>

Muestra un tag HTML de tipo <select> permitiendo selecciones mltiples. El tamao
de visualizacin es 1 (atributo size).
Este componente est diseado para situaciones en las que se necesita mostrar un
men de opciones al usuario para permitirle seleccionar mltiples opciones pero
utilizando un men que solo muestra una opcin a la vez.
La principal diferencia entre los select y los mens en JSF es el atributo size. Los
mens siempre tienen el size en 1 mientras que las listas pueden tener el tamao
variable.
NOTA: Este componente no se visualiza correctamente en todos los navegadores.
Tag <h: panelGrid>

Es un contenedor tabular para otros componentes y es visualizado como una tabla
HTML. Los componentes hijos son visualizados como celdas dentro de la tabla.
CIBERTEC
117
Tag <h: panelGroup>

Este componente crea un contenedor para agrupar a un conjunto de componentes
bajo un padre. Al visualizar los componentes hijos, se usa el tag HTML <span>.
Tag <h: dataTable>
Este componente genera un contenedor tabular para otros componentes hijos.
Tag <h: column>
Este tag sirve como hijo del tag <h: dataTable>.
2.2.5. Librera User Interface

El namespace con el que se declara es http://java.sun.com/jsf/facelets y se le asigna
el prefijo ui.
Sus tags han sido explicados en el tema de Facelets y Templates.
2.2.6. Librera de Componentes Compuestos.
El namespace con el que se declara es http://java.sun.com/jsf/composite

asigna el prefijo composite.
y se le
Esta librera solo se declara y utiliza en pginas que requieren el empleo de

componentes compuestos JSF.
CIBERTEC
118
Resumen
1. La librera CORE: se asocia al namespace f: y proporciona utilidades para
validacin, conversin, internacionalizacin, etc.
2. La librera HTML: se asocia al namespace h: y est diseada especficamente
para clientes HTML.
3. La librera de tags para Plantillas FACELET: asociada al namespace ui: permite
agregar funcionalidades de plantillas y formatos. Fue introducida en JSF 2.0.
4. La librera de tags para Componentes Compuestos: introducida tambin con JSF
2.0, se registra bajo el namespace cc:.
unidad:
JSF: http://javaserverfaces.java.net/users.html
CIBERTEC
119
2.3. INTEGRACIN JSF Y JPA

2.3.1. Introduccin
JSF proporciona componentes para manejar los aspectos de conversin y validacin
en el desarrollo de aplicaciones:
Conversin: la realizan los Converters y garantiza que los datos sean del tipo
esperado.
Los
converters
implementan
la
interfaz
javax.faces.convert.Converter.
Validacin: la realizan los validators para garantizar que los datos sean
vlidos en funcin a las restricciones de la aplicacin. Los validators son
implementaciones de la interfaz javax.faces.validator.Validator.
Es importante conocer que los converters al realizar una transformacin de datos,

requieren ser asociados tanto a componentes de entrada como de salida. Mientras
que los validators solo se asocian a componentes de entrada.
Adicionalmente, JSF proporciona un sistema de mensajes que permite a los
desarrolladores controlar la visualizacin de los mensajes de conversin y validacin
en las pginas, de una manera flexible utilizando uno o ms tags de tipo <h:
message> o <h: messages>.
2.3.2. El sistema de Conversin de JSF
En la fase denominada Apply Request Value es justamente donde se ejecuta la

conversin de los valores que llegan desde el formulario hacia el tipo de dato
apropiado. Si la conversin es exitosa, los valores pasan a ser validados.
Todos los objetos que cumplan la funcin de converters deben implementar a la
interfaz javax.faces.convert.Converter.
Esta interfaz tiene dos mtodos:
Donde:
El parmetro context es la instancia FacesContext del request.
El parmetro component es el componente cuyo valor ser convertido.
El parmetro value es el valor a ser convertido.
El mtodo getAsObject es invocado durante el procesamiento de entrada, para
convertir los valores String que llegan en el request, al tipo de dato deseado.
CIBERTEC
120
El mtodo getAsString es invocado durante la fase de salida para mostrar los valores
en formato de String en cualquiera de las tecnologas de rendering que soporta el
cliente.
Si se lanza una excepcin de tipo ConverterException, el componente se marca
como invlido y se coloca un mensaje en el FacesContext.
Los convertidores estndares son:
Todos los converters se puede llamar usando el tag <f: converter> y especificando
el ID, a excepcin de DateTimeConverter y NumberConverter que tienen sus propios
tags: <f: convertDateTime> y <f: convertNumber>.
La forma implcita de conversin se realiza cuando JSF conoce el tipo de dato del
valor. Por ejemplo, asumiendo que age es un atributo de tipo Integer del managed
bean user, en el siguiente caso la conversin es implcita:
La forma explcita es cuando se usan los tres tags que proporciona la librera core de
JSF.
Tag #1: <f: convertDateTime>
CIBERTEC
121
Donde:
El dateStyle puede ser: short, medium, long, full o default.
El valor de type puede ser: date, time o both (default).
El valor de binding es una expresin que apunta a un mtodo de una clase
que implementa la interfaz javax.faces.convert.Converter.
Tag #2: <f: convertNumber>
Donde:
type puede ser number, currency o percentage.
currencyCode es el cdigo ISO 4217 de las monedas. Por ejemplo, USD es
para los dlares americanos y EUR para el euro. Para la moneda peruana se
tiene el cdigo PEN.
currencySymbol se puede especificar para indicar el smbolo de la moneda a
utilizar (pero se debe tener en cuenta que esto es vlido con JDK 1.4 o
superior). El atributo currencyCode toma preferencia sobre este.
groupingUsed es un flag boolean que sirve para indicar cuando se debe usar
un delimitador.
Tag #3: <f: converter>
Donde:
converter-id es el valor registrado en el archivo faces-config.xml de la
aplicacin.
Para vincular un Componente UI con un converter, simplemente hay que anidar el

converter dentro del tag:
CIBERTEC
122
2.3.3. El sistema de Validacin de JSF

La interfaz javax.faces.validator.Validator es el ncleo del sistema de validaciones
de JSF. Todos los objetos que cumplan la funcin de validadores deben implementar
esta interfaz.
Dicha interfaz tiene un nico mtodo:
Este mtodo es invocado durante la fase de Apply Request Values si el componente

est marcado como Inmediato o durante la fase de Process Validations en caso
contrario.
Antes de invocar al mtodo, JSF marca al componente como invlido.
El mtodo lanza la excepcin ValidatorException si ocurre un error durante la
validacin: se almacena un mensaje en el FacesContext.
En caso no ocurran errores, el componente recin se marca como vlido.
A diferencia de los converters, los validators se registran por validator-id debido a
que el concepto de validacin no est asociado al tipo del objeto.
Adicionalmente, JSF proporciona la facilidad de usar el atributo required en los tags.
Si esta propiedad est presente, se ejecutan las validaciones.
Los validadores estndares son los siguientes:
Validator-ID
javax.faces.DoubleRange
Tag Handler
f:validateDoubleRange
javax.faces.Length
f:validateLength
javax.faces.LongRange
f:validateLongRange
javax.faces.Bean
f:validateBean
Descripcin
Valida que el tipo de
dato sea
java.lang.Double y se
encuentre dentro del
rango especificado.
dato sea String y que
tenga la longitud mnima
especificada en el
parmetro.
dato sea java.lang.Long
y se encuentre dentro
del rango especificado.
Sirve para indicar que el
valor sea validado por el
framework de validacin
CIBERTEC
123
javax.faces.RegularExpression f:validateRegex
javax.faces.Required
f:validateRequired
EE.
Permite el uso de
expresiones regulares
Tiene la misma
funcionalidad que el
atributo required:
campo obligatorio.
Para que JSF no valide campos que estn vacos se debe agregar lo siguiente al
web.xml:
Los validadores se pueden asociar a los componentes UI de dos maneras: usando

tags de la librera core o utilizando el MethodBinding.
Usando los tags de la librera core: <f:validateDoubleRange>,

<f:validateLongRange> y <f:validateLength>
Usando el MethodBinding:
En este caso, se asocia a un mtodo del managed bean user:
2.3.4. El sistema de Mensajes de JSF
Los mensajes de error generados en la validacin o en la conversin fluyen hacia el

usuario mediante la clase javax.faces.application.FacesMessage, el contexto
FacesContext y los componentes UIMessage y UIMessages.
La clase FacesMessage encapsula los mensajes que describen los problemas de
conversin y validacin. Posee tres propiedades interesantes:
severity: que puede ser INFO, WARN, ERROR, FATAL.
CIBERTEC
124
summary: contiene los mensajes de forma comprensible para el usuario.

detail: contiene los mensajes de forma comprensible para el usuario.
La instancia de FacesContext mantiene dos colecciones de instancias

FacesMessage que pueden ser accedidas por diferentes formas del mtodo
getMessages ():
Una de mensajes asociados con un componente.
La otra de mensajes que no estn asociados con el componente.
El mtodo getMessages () de la instancia FacesContext:
Sin argumentos retorna un Iterator de todos los mensajes (estn asociados o
no con el componente).
Con el argumento clientId retorna solo los mensajes asociados con ese
clientId. Si el clientId es NULL, retorna los mensajes que no estn asociados
con un valor especfico de clientId.
EN QU MOMENTO SE GENERAN LOS MENSAJES?

Existen tres momentos dentro del ciclo de vida del request cuando los componentes
generan instancias de FacesMessage y las agregan al FacesContext:
1. Cuando falla una conversin.
2. Cuando falla una validacin.
3. Cuando los datos, una vez convertidos y validados no pueden ser actualizados
en el modelo durante la fase denominada Update Model Values.
En el caso de la conversin, un error significa el lanzamiento de la excepcin
ConverterException. La severidad de ste error siempre es ERROR. El converter
tiene dos opciones:
1. No enva parmetros al ConverterException, en cuyo caso, se genera un
FacesMessages con el mensaje conversin failed.
2. Se enva como parmetro una propiedad message, cuyo valor se utiliza como
la propiedad detail de FacesMessage.
En el caso del validador, un error significa el lanzamiento de la excepcin
ValidatorException, el cual siempre enva un FacesMessage en su constructor. La
severidad de la excepcin siempre est a nivel de ERROR.
En el caso de la actualizacin del modelo, cuando se lanza una excepcin EL, se
examina el mensaje de la excepcin. Si no es null, se crea un FacesMessage con el
mensaje como atributo summary. Si es null, se crea un FacesMessage con un
mensaje de error genrico.
CMO SE AGREGAN LOS MENSAJES?

Se tiene que agregar al FacesContext.
CIBERTEC
125
CMO SE VISUALIZAN LOS MENSAJES?

Existen dos componentes estndares que permiten visualizar los mensajes:
UIMessages y UIMessage. En base a esos componentes, el kit de HTML tiene dos
renderers: javax.faces.Messages y javax.faces.Message respectivamente, de
manera tal que los tags a emplear son: <h: messages> y <h: message> que se
encuentran en la librera html.
a) Mostrando mensajes para un componente especfico: al tag <h: message> se
le debe proporcionar el atributo for para indicar el componentId acerca del
cual se mostrarn los mensajes. De esta manera, el desarrollador puede
colocar los mensajes en cualquier lugar de la pgina.
b) Mostrando mensajes para todos los componentes: si se coloca el tag <h:
messages> en algn lugar de la pgina, todos los mensajes que se encuentran
en el FacesContext son mostrados a menos que se configure el atributo
globalOnly (en cuyo caso solo se muestran los mensajes que no estn
asociados a un determinado componente). Adems, se puede especificar el
atributo layout con los valores de list (los mensajes se muestran como
una lista HTML sin orden alguno) o table (los mensajes se muestran como
tabla HTML).
c) Personalizando los mensajes: el contenido de los mensajes por defecto puede
ser poco claro para efectos de una aplicacin. Es posible proporcionar un
Resource Bundle (archivo .properties) con los mensajes que se desea
manejar y de esa forma sobre escribir los mensajes por defecto de JSF.
Para ello se debe agregar el siguiente bloque al archivo faces-config.xml:
CIBERTEC
126
Tener en cuenta que este archivo requiere que los tags vayan en cierto orden
(debido al DTD). En este ejemplo se est indicando que el archivo de mensajes
se llama MyMessages.properties y que los idiomas soportados son espaol e
ingls.
Adems, se debe tener en cuenta que para sobre escribir los mensajes por
defecto, el archivo de mensajes debe tener como key los messagesID del
framework y como value, los textos que se desea para la aplicacin.
Algunos de los messageID estndares que pueden ser sobre escritos son:
javax.faces.component.UIInput.CONVERSION
javax.faces.component.UIInput.REQUIRED
javax.faces.component.UISelectOne.INVALID
javax.faces.component.UISelectMany.INVALID
javax.faces.converter.BigDecimalConverter.DECIMAL
javax.faces.converter.BigIntegerConverter.BIGINTEGER
javax.faces.converter.BooleanConverter.BOOLEAN
javax.faces.converter.ByteConverter.BYTE
javax.faces.converter.CharacterConverter.CHARACTER
javax.faces.converter.DateTimeConverter.DATE
javax.faces.converter.DateTimeConverter.TIME
javax.faces.converter.DateTimeConverter.DATETIME
javax.faces.converter.DateTimeConverter.PATTERN_TYPE
javax.faces.converter.DoubleConverter.DOUBLE
javax.faces.converter.FloatConverter.FLOAT
javax.faces.converter.IntegerConverter.INTEGER
javax.faces.converter.LongConverter.LONG
javax.faces.converter.NumberConverter.CURRENCY
javax.faces.converter.NumberConverter.PERCENT
javax.faces.converter.NumberConverter.NUMBER
javax.faces.converter.NumberConverter.PATTERN
javax.faces.converter.ShortConverter.SHORT
javax.faces.converter.STRING
javax.faces.validator.NOT_IN_RANGE
javax.faces.validator.DoubleRangeValidator.MAXIMUM
javax.faces.validator.DoubleRangeValidator.MINIMUM
javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE
javax.faces.validator.DoubleRangeValidator.TYPE
javax.faces.validator.LengthValidator.MAXIMUM
javax.faces.validator.LengthValidator.MINIMUM
javax.faces.validator.LongRangeValidator.MAXIMUM
javax.faces.validator.LongRangeValidator.MINIMUM
CIBERTEC
127
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE
javax.faces.validator.LongRangeValidator.TYPE
Se puede editar el archivo messages.properties que se encuentra en el jar de las

APIs de JSF y ver todas las llaves disponibles.
2.3.5. El modelo de Eventos de JSF

JSF proporciona un modelo de programacin basado en eventos que es muy similar al
que se utiliza en el desarrollo de aplicaciones Swing o AWT. Esto permite un mejor
control de interfaces de usuario complejas debido a que los componentes de dicha
interfaz publican cambios en sus estados (eventos) hacia un conjunto de objetos que
actan como listeners y que ejecutan las tareas requeridas.
Hay dos tipos de eventos:
Los eventos de aplicacin
Los eventos de ciclo de vida
Los eventos pueden ser publicados a lo largo del ciclo de vida de una aplicacin JSF.
Este ciclo de vida puede ser dividido en tres etapas:
inicio (start-up).
ejecucin de procesamiento del ciclo de vida del request. La mayor parte del
tiempo, la aplicacin se ejecuta en esta etapa.
finalizacin (shutdown).
CIBERTEC
128
Los eventos publicados durante la etapa de procesamiento del ciclo de vida de los
request se muestran en el siguiente grfico:
Los eventos que ocurren durante el start-up son:

PostConstructApplicationEvent
Los eventos que ocurren durante el Shutdown son:
PreDestroyApplicationEvent
Los eventos que ocurren en cualquier momento del ciclo de vida de la aplicacin:
ExceptionQueuedEvent
PostConstructCustomScopeEvent
PreDestroyCustomScopeEvent
PostConstructViewMapEvent
PreDestroyViewMapEvent
PostAddToViewEvent
PreRemoveFromViewEvent
EVENTOS DE APLICACIN
Tipo de Evento
ActionEvent
ValueChangeEvent
Momento en el que se procesa

Al completar la fase denominada Invoke
Application a menos que se use el flag
immediate con el valor true en cuyo
caso se procesa al final de la fase Apply
Request Value.
Al finalizar la fase de Process
Validations a menos que el flag
immediate est en true, en cuyo caso
se procesa al final de la fase Apply
Request Value.
CIBERTEC
129
En general, para manejar eventos Faces se puede escribir una clase listener que
implemente la interfaz apropiada (javax.faces.event.ActionListener) y que se vincule al
componente (en este caso, al UIComponent).
Para Action Events sin embargo, se puede escribir: o un mtodo en una clase
Action o un mtodo en una clase Listener. La explicacin es la siguiente:
a) Un action method es un simple mtodo Java que tiene lugar en un managed
bean, no tiene argumentos y retorna un String. Estos action methods son
manejados por un ActionListener, que por defecto toma el valor del String y lo
enva al NavigationHandler con el fin de determinar el siguiente paso de
navegacin.
Un action method se asocia a un UIComponent con el atributo action.
Ejemplo:
b) Si no se requiere navegacin, se utilizan los action listener method, que es un

mtodo que simplemente se ejecuta y que no devuelve resultados (retorna
void). Se asocia a un UIComponent con el atributo actionListener.
Los Value Change Events son eventos que se emplean para indicar que el valor
de un componente UI ha cambiado. Generalmente, se emplea para componentes que
implementan las interfaces ValueHolder o EditableValueHolder.
CIBERTEC
130
Al igual que los action events, los value change events pueden manejarse de la
misma manera.
Sin embargo, debe tenerse presente que el evento ocurre cuando se hace el submit
del formulario. Es ms, el evento sucede en la fase de Process Validations. Un
siguiente envo del formulario sin alterar el valor, no genera que se dispare el evento
debido a que no ha cambiado el valor del campo.
Si se agrega el atributo immediate y se configura en true, se puede disparar el
evento de cambio en la fase deApply Request Values.
Para personalizar los Listeners se debe tener en cuenta que:

Si se implementa la interfaz ActionListener se debe anidar dentro del
componente UI el siguiente tag:
Si se implementa la interfaz ValueChangeListener se debe anidar dentro del

componente UI el siguiente tag:
EVENTOS DE FASE
Los eventos de fase
(o Phase Events) se procesan entre cada fase del
procesamiento de ciclo de vida de un request.
Se puede crear un Listener simplemente implementando la interfaz PhaseListener.
Esta interfaz posee tres mtodos que deben ser implementados:
beforePhase()
afterPhase()
getPhaseId()
CIBERTEC
131
Los mtodos beforePhase () y afterPhase () se ejecutan para todas las fases del ciclo
de procesamiento de un request, por tanto, si se desea ejecutar alguna lgica especial
en determinada fase, se deber obtener el ID de la fase y en base a condiciones,
controlar el flujo del cdigo.
El mtodo getPhaseId () sirve para determinar a qu fase est asociado el listener.
Cuando se usa para cualquier fase retorna el valor ANY_PHASE:
Finalmente, el listener debe registrarse en el faces-config.xml:
EVENTOS DE SISTEMA
Este tipo de eventos fueron introducidos con la especificacin JSF 2.0 y proporcionan
mayores detalles que los ofrecidos por los eventos de fase.
CIBERTEC
132
Resumen
1. Dentro del procesamiento del ciclo de vida de un request, lo primero que se
ejecuta es la conversin de datos que llegan desde el request. SI todo funciona
bien, recien se ejecuta la validacin de los mismos.
2. Un conversor personalizado implementa la interfaz javax.faces.convert.Converter.
El mtodo getAsObject se aplica cuando se reciben los datos del request y el
mtodo getAsString se aplica para devolver la visualizacin al cliente.
3. Un validador personalizado implementa la interfaz javax.faces.validator.Validator.
Tiene un nico mtodo validate en donde se debe escribir la lgica de validacin
deseada.
4. Los mensajes de error se muestran con los tags <h: message> y <h: messages>.
Para personalizarlos, se requiere definir el archivo de recursos en el facesconfig.xml
5. Los eventos ms utilizados en JSF estn relacionados con la pulsacin de
botones o el cambio de valores en la pgina: ActionEvent y ValueChangeEvent.
unidad:
o
JSF: https://javaserverfaces.java.net/
CIBERTEC
133
2.4. INTEGRACIN JSF Y JPA

2.4.1. JSF y AJAX
JSF se constituye en el mejor framework que se integra y facilita el uso de las
capacidades de Ajax.
El concepto de AJAX corresponde a un conjunto de tecnologas (Hojas de estilo,
JavaScript, Document Object Model, etc.) que permiten ejecutar llamadas asncronas
al servidor y procesar la respuesta modificando el rbol DOM que se almacena en el
navegador.
JSF proporciona dos maneras de trabajar con AJAX, la primera forma es mediante un
tag nuevo identificado como <f: ajax> mediante el cual no hay que preocuparse
acerca del uso de javaScript. La segunda forma es el uso de una API de JavaScript
llamada jsf: ajax.request () que proporciona un puente estndar para las peticiones
de tipo Ajax.
TAG <f: ajax>
JSF proporciona un tag para el manejo de llamadas AJAX: <f: ajax>, que al igual que
otros tags de la librera core, no puede ser empleado aisladamente. Es decir, debe ser
anidado o debe contener a otros tags que se asocien con un Componente UI.
Los atributos que acepta este tag pueden dividirse en dos:
Atributos que actan sobre el server-side
Atributo
Valor
execute
Lista de IDs separada por comas, expresin que se
evala como lista o palabra reservada.
render
listener
immediate
disabled
Indica los valores a ser enviados en el POST.

Lista de IDs separada por comas, expresin que se
evala como lista o palabra reservada.
Indica la porcin de la vista (subtree) a ser renderizada.
Expresin que invoca a un mtodo Java. Dicho mtodo
tiene la siguiente firma:
void mtodo( AjaxBehaviourEvent abe )
Si el valor no es nulo, el mtodo es invocado durante la
fase denominada Invoke Application en el
procesamiento del ciclo de vida del request.
True/false o alguna expresin que devuelva uno de esos
valores.
True/false o alguna expresin que devuelva uno de esos
valores. Si es true, el tag est deshabilitado.
Atributos que actan sobre el client-side

Atributo
Valor
event
String que contiene uno de los nombres de eventos
CIBERTEC
134
soportados.
onevent
onerror
Cuando sucede el evento, se enva un request de tipo

POST hacia el servidor.
Nombre (o Expresin que devuelve un nombre) de una
funcin JavaScript que acepta un argumento y que
maneja el status del request/response.
Nombre (o Expresin que devuelve un nombre) de una
funcin JavaScript que acepta un argumento y que
maneja el status del request/response.
Si no es especfica y el modo Development est
configurado, solo la implementacin JSF Mojarra muestra
un dilogo de alerta.
Por default, todos los componentes UI de captura de datos disparan el evento

valueChange.
Ejemplo:
JAVASCRIPT ESTNDAR
Todas las implementaciones de JSF 2 deben contener una librera denominada
javax.faces la cual contiene un Script llamado jsf.js que expone una serie de
APIs estndares para ejecutar las invocaciones Ajax.
Existen dos objetos principales dentro del javaScript: ajax y til. El objeto ajax tiene
las funciones siguientes:
Funcin JavaScript
addOnError(callback)
addOnEvent(callback)
request(source, event, options)
response( request, context )
Significado
Proporciona la misma implementacin
que el atributo onerror del tag <f:ajax>
Proporciona la misma implementacin
que el atributo onevent del tag <f:ajax>
Proporciona la misma implementacin de
la parte del request del tag <f:ajax>
Proporciona la misma implementacin de
manejo del response que el tag <f:ajax>
CIBERTEC
135
La funcin ms importante es request, la cual toma tres parmetros:

source: es el elemento DOM que dispara el requerimiento Ajax. Normalmente
su valor es this.
event: es opcional y corresponde al evento DOM que dispara el requerimiento
Ajax. Se usa normalmente para recuperar informacin adicional sobre el evento
(por ejemplo que tecla fue presionada).
options: tambin es opcional. Contiene una lista de llaves y valores segn la
relacin siguiente:
execute: lista de IDs (separadas por comas) a ser procesada durante el
request.
render: lista de IDs (separadas por comas) a ser reemplazados durante el
response.
onevent: Funcin JavaScript a ser invocada para el evento.
onerror: Funcin JavaScript a ser invocada si hay un error.
params: parmetros a ser incluidos en el request.
Las opciones ms importantes son execute y render y bajo JSF 2 permiten el
concepto de vista parcial: es un mecanismo que permite que el procesamiento de
ciclo de vida de un request se ejecute sobre uno o ms componentes. Solo los
componentes identificados en el request sufren el proceso de validacin, conversin y
actualizacin del modelo. De igual forma, en el render, solo los componentes
indicados sufren la actualizacin en el rbol DOM sin tener que refrescar toda la
pgina.
Adicionalmente, en lugar de identificar cada uno de los componentes para el execute
y el render, se puede emplear algunos toquen:
Token
@all
Significado
Todos los componentes de la vista
@none
Ningn componente ( es el default para el render )
@this
Es el componente que dispara el evento (valor por defecto

para execute)
@form
Todos los componentes del formulario
Para poder utilizarla la librera JavaScript es preciso incorporar en la pgina Faces el

siguiente tag:
Este tag le dice a JSF que coloque el script en la cabecera de la pgina.

Luego, al componente UI se le define el atributo correspondiente al evento que se
desea manejar:
CIBERTEC
136
En este caso, se define el evento onkeypress: cada vez que se pulse una tecla, dicho
valor aparecer en el campo con id outNombre.
2.4.2. Integracin JSF + JPA

Las entidades JPA tambin pueden funcionar como Managed Beans simplemente
agregando las anotaciones @ManagedBean y la anotacin de mbito respectivo (por
ejemplo @RequestScoped).
Es aconsejable emplear JSF 2 con EJB 3.0 y JPA para que el contenedor de EJBs
controle las transacciones. Sin embargo, se puede utilizar directamente JPA pero se
debe tener en cuenta que hay que manejar la persistencia y las transacciones de
forma manual.
Enterprise Java Beans (EJB) es una arquitectura de componentes Java en el

lado servidor que permite el desarrollo rpido y simplificado de aplicaciones
portables, distribuidas, transaccionales y seguras basadas en la plataforma
Java EE.
Java PErsistence API (JPA) es un framework basado en Java que permite

manejar datos relacionales en aplicaciones que emplean Java SE o Java EE.
En todo caso, si se emplea la tecnologa de EJB 3.0, se requiere contar con un

servidor de Aplicaciones como WebSphere de IBM, Oracle WebLogic o JBoss, dado
que Apache Tomcat no soporta contenedores de EJB.
Al igual que con Struts 2, se requiere el archivo persistence.xml dentro del folder
META-INF y las libreras de la implementacin de JPA (para el curso es
EclipseLink).
Un ejemplo de managed bean con JPA:
CIBERTEC
137
Observe que se controla la excepcin en caso no existan datos: se coloca un mensaje

en el contexto de JSF para emplear luego el tag <h: messages /> en la pgina de
login.
2.4.3. Empleando otras implementaciones de JSF

Como se haba mencionado, JSF es una especificacin, la cual est soportada por
diversas implementaciones. Cada implementacin proporciona un conjunto de tags
que presentan determinada funcionalidad, la cual debe ser evaluada segn las
necesidades del proyecto.
Lo bueno de trabajar con las implementaciones es que en la mayora de casos, todas
pueden coexistir dentro de una pgina.
Una implementacin ligera que contiene un nico archivo .jar, no requiere
configuracin y no tiene dependencias (a diferencia de Apache MyFaces) es
PrimeFaces ( http://www.primefaces.org ).
PrimeFaces proporciona un conjunto de componentes muy interesantes con un gran
diseo y funcionalidad a la vez que le otorga un tratamiento especial al tema de Ajax
como veremos en el siguiente ejemplo.
Descargar la librera (para JSF 2)
desde el URL de Primefaces
http://www.primefaces.org/downloads.html ) y configurar el Build Path del proyecto.
CIBERTEC
138
No olvidar de configurar tambin el CLASSPATH del servidor. Si el servidor es

Tomcat, debe quedar as:
A continuacin se muestra el encabezado de la pgina XHTM. Note que la librera de

PrimeFaces est identificada como p:
CIBERTEC
139
Y el fragmento de cdigo que emplea Tags de PrimeFaces:
El proceso es bastante sencillo: se debe ingresar un ID que ser verificado cuando el

usuario presione el enlace de verificacin. Este ID ser validado disparando la accin
denominada nickAction del Managed Bean utilizando AJAX.
El tag p: ajaxStatus controlar el procesamiento de la peticin AJAX y mostrar u
ocultar la figura ajax-loading.gif
El cdigo del ManagedBean:
CIBERTEC
140
Y Lo que se debe visualizar en el navegador. Observe el diseo ms elaborado.
CIBERTEC
141
2.4.4. Tablas JSF: Facets, dataTable y panelGrid.

Tag <f: facet />
Este tag establece que el componente anidado tiene una relacin especial con el
componente padre.
Un facet representa una seccin identificada con un nombre (el nico atributo que
tiene es name) dentro de un componente UI que acta como contenedor.
Normalmente se puede observar su utilizacin con componentes UI complejos (como
PanelGrid o DataTable).
Por ejemplo, los ttulos que forman el encabezado de una tabla, en estricto, no forman
parte de la relacin con el componente padre, por tanto son candidatos a ser definidos
como facets. Durante el rendering del componente padre, todos los tags facet son
mostrados tambin.
Ejemplo:
Esto mostrar algo similar a esto (asumiendo que el valor de beanLogin.clave es

TEST1
Tag <h: column />

Este tag sirve como un hijo inmediato del tag <h: dataTable>. Sirve para la definicin
de columnas y puede ser equipado con facets llamados header y footer para
crear encabezados y pies en las tablas.
Los atributos que soporta son:
Atributo
binding
id
rendered
CIBERTEC
Tipo
Expresin que
retorna un valor
String
boolean
Descripcin
La referencia a una instancia de opcional
un componente UI.
Identificador del componente.
opcional
Indica si el componente se opcional
mostrar durante la fase Render
142
footerClass
String
headerClass
String
Response. Por defecto es true.

Lista (separada por comas) de los opcional
estilos que se aplicarn al footer
de esta tabla.
Lista (separada por comas) de los opcional
estilos que se aplicarn al header
de esta tabla.
Tag <h: dataTable />

Este tag permite solucionar aquella situacin en la cual el controlador genera una lista
de datos de tamao variable y el desarrollador se enfrenta al problema de generar la
pgina de salida sin tener la obligacin de usar scripting o hacer iteraciones.
Este tag genera una tabla HTML a partir de una coleccin de objetos, donde los
componentes anidados (tag <f: column>) son responsables de mostrar las columnas
de la tabla. Las columnas pueden contener cualquier tipo de componente.
El cuerpo de la tabla se muestra dentro del tag HTML <tbody>.
Los datos se muestran en celdas y las filas se van agregando a medida que se
completa la cantidad de columnas definidas.
Los eventos que soporta el componente son: onclick, ondblclick, onkeydown,
onkeypress, onkeyup, onmousedown, onmousemove, onmouseout, onmouseover,
onmouseup.
Los atributos de formato/agrupamiento son:
Atributo
bgcolor
Tipo
String
border
int
cellpadding
int
cellspacing
int
first
int
frame
rendered
String
boolean
Descripcin
El color de fondo de la tabla
HTML generada
El tamao (en pixels) del borde
de la tabla HTML generada
El atributo cellpadding de la
tabla HTML generada
El atributo cellspacing de la
tabla HTML generada
Primera fila a ser mostrada (inicia
en cero )
Especifica en qu lado del frame
se mostrar la tabla:
none
above
below
hsides
vsides
lhs
rhs
box
border
Indica si el componente se
Opcional
Opcional
Opcional
Opcional
Opcional
Opcional
Opcional
CIBERTEC
rows
int
rules
String
summary
String
var
String
width
String
143

Determina cuantas filas se
mostrarn en la tabla HTML
generada
Atributo rules pasado a la tabla
HTML generada. Indica si se
muestra la trama de celdas (como
en excel):
none
groups
rows
cols
all
Atributo summary que se enva
a la tabla HTML generada.
Genera una descripcin pero no
es visible en la mayora de
navegadores.
Es una variable EL que permite
iterar sobre los datos. Representa
el valor actual en una iteracin
sobre el atributo value.
Es el atributo width pasado a la
table HTML generada (en pixels
es un nmero entero y en
porcentaje lleva el smbolo
respectivo).
Opcional
Opcional
Opcional
Opcional
Opcional
Los atributos core que soporta son:

Atributo
binding
id
title
value
Tipo
Expresin que
retorna un valor
String
String
String
Descripcin
La referencia a una instancia de
un componente UI
Identificador del componente
El ttulo del componente. Se pasa
a la tabla HTML generada
El valor del componente
opcional
opcional
opcional
opcional
Los atributos de estilo:

Atributo
columnclasses
Tipo
String
footerclass
String
headerclass
String
rowclasses
String
CIBERTEC
Descripcin
Lista (separada por comas) de
los estilos que se aplicarn a las
columnas.
Los estilos CSS se aplican
repetidamente a las columnas de
un componente panelGrid
El estilo aplicado a la ltima fila
de la tabla.
El estilo aplicado a la primera fila
de la tabla.
opcional
opcional
opcional
opcional
144
style
String
styleclass
String

filas.
repetidamente a las filas de un
componente panelGrid
Estilo(s) en lnea que se opcional
aplicar
al
componente
panelGrid.
Estilo(s) CSS que se aplicar al opcional
componente panelGrid.
La sintaxis bsica es:
Donde el tipo de dato de value puede ser: Array, List, ResultSet, Result (JSTL),
DataModel (JSF).
Ejemplo 1:
Asumiendo que el Managed Bean denominado company1 tienen un atributo

programmers que devuelve un arreglo de Programadores. Se puede obtener la
siguiente pantalla:
Ejemplo 2: Ahora usando encabezados y definiendo facets (tag <f: facet>)
CIBERTEC
145
Genera la siguiente pantalla:
Ejemplo 3: Usando estilos

Note que el encabezado de la tabla tiene un estilo. As tambin, las filas pares e
impares se manejan con estilos diferentes (obviamente la Hoja de estilos debe estar
definida como recurso en la aplicacin).
CIBERTEC
146
Se mostrar una pantalla similar a la siguiente:
Tag <h: panelGrid />

Este tag genera una tbla HTML que sirve como contenedor para otros componentes.
Los componentes hijos son visualizados como celdas.
Los eventos que soporta: onclick, ondblclick, onkeydown, onkeypress, onkeyup,
Onmousedown, onmousemove, onmouseout, onmouseover y onmouseup.
Algunos de los atributos:
Atributo
bgcolor
Tipo
String
border
int
cellpadding
int
Descripcin
El color de fondo de la tabla Opcional
HTML generada
El tamao (en pixels) del borde Opcional
de la tabla HTML generada
El atributo cellpadding de la Opcional
tabla HTML generada
CIBERTEC
cellspacing
int
columns
int
frame
rendered
String
boolean
rules
String
summary
String
width
String
147
El atributo cellspacing de la
tabla HTML generada
Nmero de columnas a ser
generadas en la tabla HTML
Especifica en qu lado del frame
se mostrar la tabla:
none
above
below
hsides
vsides
lhs
rhs
box
border
Indica si el componente se
Atributo rules pasado a la tabla
HTML generada. Indica si se
muestra la trama de celdas (como
en excel):
none
groups
rows
cols
all
Atributo summary que se enva
Genera una descripcin pero no
es visible en la mayora de
navegadores.
Es el atributo width pasado a la
table HTML generada (en pixels
es un nmero entero y en
porcentaje lleva el smbolo
respectivo).
Opcional
Opcional
Opcional
Opcional
Opcional
Opcional
Opcional
Los atributos core que soporta son:

Atributo
binding
id
title
Tipo
Expresin que
retorna un valor
String
String
Descripcin
La referencia a una instancia de opcional
un componente UI.
Identificador del componente.
opcional
El ttulo del componente. Se pasa opcional
Los atributos de estilo:

Atributo
CIBERTEC
Tipo
Descripcin
148
columnclasses
String
footerclass
String
headerclass
String
rowclasses
String
style
String
styleclass
String

columnas.
repetidamente a las columnas de
un componente panelGrid.
El estilo aplicado a la ltima fila
de la tabla.
El estilo aplicado a la primera fila
de la tabla.
filas.
repetidamente a las filas de un
componente panelGrid
Estilo(s) en lnea que se
aplicar
al
componente
panelGrid.
Estilo(s) CSS que se aplicar al
componente panelGrid.
opcional
opcional
opcional
opcional
opcional
opcional
DATAMODEL
Un DataModel es una abstraccin arbitraria alrededor de alguna tecnologa que puede
ser usada para adaptar una variedad de fuentes de datos para ser empleados por
componentes JSF de tal forma que soporten el procesamiento fila por fila por parte de
los componentes hijos.
La coleccin de datos se modelo como una coleccin de filas de objetos, las cuales
pueden ser accedidas por un cursor (que inicia en cero) conocido como row index. La
API proporciona una serie de mecanismos para posicionar los cursos y recuperar los
objetos.
2.4.5. Mantenimiento de tablas

Se presenta un ejemplo sencillo de mantenimiento usando tablas.
Crear una clase Item.java que tenga la siguiente estructura (no olvidar los
getter/setter)
CIBERTEC
149
Crear una clase Bean.java (que es el managed bean de la aplicacin) que tenga la
siguiente estructura. Observe que se utiliza la clase DataModel:
Ahora, codificar los mtodos:
CIBERTEC
150
Y el mtodo que controla la edicin:
No olvidar los getter/Setter de tem, model y list.

Ahora codificar el FaceLet.
La primera parte de la pgina es:
CIBERTEC
151
Hasta aqu, se debe mostrar los datos y los botones de edicin y borrado.
Ahora, codificar la parte de edicin:
CIBERTEC
152
El resultado final es una pantalla similar a la siguiente, que permite la edicin,

eliminacin y adicin de elementos en una tabla.
CIBERTEC
153
Resumen
1. JSF 2 soporta Ajax de dos formas: la primera es mediante el uso de la API de
JavaScript: jsf,ajax.request(); la segunda forma es mediante el tag <f:ajax>
2. La API de JavaScript proporciona un puente para el manejo de las peticiones
ajax y permite un cierto nivel de control.
3. El tag <f: ajax> permite que el programador se olvide del JavaScript.
4. Para integrar JSF con JPA, slo debe configurarse los archivos requeridos por
JPA. El resto de temas se manejan con la unidad de persistencia y el
EntityManager.
5. JSF proporciona una manera fcil de visualizar datos sin tener que realizar
iteraciones en la pgina, mediante el uso del tag <h:dataTable>
6. Las tablas se pueden refrescar con Ajax o se puede convertir en tablas editables.
unidad:
CIBERTEC
AJAX: http://java.dzone.com/articles/ajax-jsf-joined
154
CIBERTEC
155
UNIDAD
3
SPRING FRAMEWORK
Al trmino de la unidad el alumno implementa una aplicacin web utilizando
Spring, donde podr integrar Spring, JSF y JPA en su aplicacin.
TEMARIO
3.1 Tema 9 : Spring Core
3.1.1 : Introduccin
3.1.2 : Arquitectura
3.2 Tema 10 : Spring Web
3.2.1 : Introduccin
3.2.2 : Configuracin
3.3 Tema 11 : Spring Mdulos
3.3.1 : Spring security
Implementar proyectos con la estructura Spring Framework.

Implementar proyectos Integrando Spring, JSF y JPA.
CIBERTEC
156
CIBERTEC
157
3.1. SPRING CORE

3.1.1. Introduccin
En la actualidad, el desarrollo de aplicaciones empresariales, aunque es ms sencillo
ya que hay muchas herramientas, APIs, y Frameworks; los cuales aunque son
opcionales, el aprender a usarlos nos ayudar a desarrollar nuestras aplicaciones en
menos tiempo y a que estas sean ms robustas y contengan menos errores.
Tambin se vuelve ms complicado porque nuestras aplicaciones deben ser capaces

de conectarse con otras aplicaciones y servicios. Adems, como desarrolladores,
somos los responsables de coordinar cada una de las partes de nuestra aplicacin
para que todo funcione correctamente.
Por si no fuera suficiente, debemos tomar en cuenta que debemos darle
mantenimiento a nuestras aplicaciones, y que en algunos casos ser necesario que
cambiemos mdulos o capas enteras de la misma para mejorarla; como por ejemplo
sustituir nuestras consultas JDBC con Hibernate en los casos en los que sea prudente.
Afortunadamente existen frameworks que nos ayudan hacindose cargo de todas o
casi todas las complicaciones mencionadas anteriormente. Spring es el ms popular
de estos super-frameworks Java. Nos proporciona varios mdulos los cuales abarcan
la mayor parte de las cosas que debemos hacer en cualquiera de las capas de
nuestras aplicaciones, desde plantillas para trabajar con JDBC o invocacin de Web
Services y JMS, pasando por sus propias soluciones, ORM o MVC (web), hasta
integracin con otros frameworks, como Struts 2, Hibernate, JSF, etc. Todo esto de
una forma elegante y haciendo uso de muchos buenos principios de programacin.
Adems Spring maneja la infraestructura de la aplicacin, por lo que nosotros solo
deberemos preocuparnos de la lgica de la misma (y de la configuracin de Spring).
Spring es, como lo definen sus autores, un framework ligero para construir
aplicaciones empresariales. Aunque Spring se encuentra dividido en distintos mdulos,
cada uno de los cuales se encarga de partes diferentes de nuestra aplicacin, no deja
de ser un monstruo, ya que es tan grande que alguien podra nunca usar todos estos
mdulos en aplicaciones pequeas o medianas; pero en aplicaciones grandes o
realmente grandes puede ahorrarnos mucho trabajo ya que puede coordinar todas las
partes de la aplicacin. Esta separacin en mdulos nos permite usar solo las partes
que necesitamos, sin tener la carga de los que no usemos.
Spring est diseado para no ser intrusivo, esto significa que no es necesario que
nuestra aplicacin extienda o implemente alguna clase o interface de Spring (si no lo
queremos), por lo que nuestro cdigo de lgica quedar libre y completamente
reutilizable para un proyecto sin Spring, o por si debemos quitarlo de una aplicacin
que ya lo est usando. Gracias a esto es posible usar un POJO o un objeto Java para
hacer cosas que antes solo podan hacerse con EJBs. Sin embargo la utilidad de
Spring no es solo para el desarrollo de aplicaciones web, o no solo en el servidor.
Cualquier aplicacin Java puede beneficiarse del uso de Spring.
El ncleo de Spring est basado en un principio o patrn de diseo llamado Inversin
de Control (IoC por sus siglas en ingls). Las aplicaciones que usan el principio de IoC
se basan en su configuracin (que en este caso puede ser en archivos XML o con
anotaciones como en Hibernate) para describir las dependencias entre sus
componentes, esto es, los otros objetos con los que interacta. En este caso
CIBERTEC
158
inversin significa que la aplicacin no controla su estructura; permite que sea el

framework de IoC (en este caso Spring) quien lo haga.
Por ejemplo, supongamos que tenemos una clase AlmacenUsuario, que depende de
una instancia de una clase UsuariosDAO para realizar su tarea. AlmacenUsuario
crea una instancia de UsuariosDAO usando el operador new u obtiene una de
algn tipo de Fbrica. Usando la tcnica de IoC, una instancia de UsuariosDAO, o
una subclase de esta, es proporcionada a AlmacenUsuario en tiempo de ejecucin
por el motor de Spring. En este caso UsuariosDAO tambin podra ser una interface
y Spring se encargar de proporcionarnos una instancia de una clase que implemente
esa interface. Esta inyeccin de dependencia en tiempo de ejecucin ha hecho que a
este tipo de IoC se le d el nombre ms descriptivo de inyeccin de dependencia (DI
por sus siglas en ingls). El concepto importante es que los componentes no saben
cul implementacin concreta de otros componentes estn usando; solo ven sus
interfaces.
El uso de interfaces y DI son mutuamente benficos, ya que hace ms flexible y
robusta nuestra aplicacin y es mucho ms fcil realizar pruebas unitarias. Pero la
complejidad de escribir cdigo que maneje las dependencias entre los componentes
de una aplicacin diseada para usar interfaces puede llegar a ser mucho y esto,
adems, hace que los desarrolladores tengamos que escribir an ms cdigo.
Afortunadamente, usando DI reducimos la cantidad de cdigo extra que debemos
escribir, para un diseo basado en interfaces, casi a cero.
En el contexto de DI, Spring acta como un contenedor que proporciona las instancias
de las clases de nuestra aplicacin todas las dependencias que necesita, pero en una
forma no intrusiva y automtica. Todo lo que debemos hacer es crear un archivo de
configuracin que describa las dependencias; Spring se har cargo del resto.
Como dije antes: Spring es un contenedor ya que no solo crea los componentes de
nuestra aplicacin, sino porque contiene y maneja al ciclo de vida y configuracin de
estos componentes. En Spring, podemos declarar cmo debe ser creado cada uno de
los objetos de nuestra aplicacin, cmo deben ser configurados, y cmo deben
asociarse con los dems.
La implementacin de DI de Spring se enfoca en el acoplamiento dbil: los
componentes de nuestra aplicacin deben asumir lo menos posible acerca de otros
componentes. La forma ms fcil de lograr este bajo acoplamiento en Java es
mediante el uso de Interfaces. Como cada componente de la aplicacin solo est
consciente de la interface de otros componentes, podemos cambiar la implementacin
del componente sin afectar a los componentes que usan el nuevo componente.
Hablar un poco ms de esto cuando veamos los ejemplos.
El uso de DI tiene como beneficios, adems de lo que ya he mencionado arriba, los
siguientes:
Reduce el cdigo pegamento: Esto quiere decir que reduce dramticamente la
cantidad de cdigo que debemos escribir para unir los distintos componentes. Aunque
algunas veces este cdigo puede ser tan simple como usar el operador new para
instanciar un nuevo objeto, otras pueden ser ms complejas, como realizar una
bsqueda de dicha dependencia en un repositorio a travs de JNDI, como en el caso
de los recursos remotos. En esto caso, el uso de DI puede reducir de forma dramtica
la cantidad de cdigo pegamento (o glue code) proporcionando bsquedas
automticas.
CIBERTEC
159
Externaliza dependencias: Como es posible colocar la configuracin de dependencias

en archivos XML podemos realizar una reconfiguracin fcilmente, sin necesidad de
recompilar nuestro cdigo. Gracias a esto es posible realizar el cambio de la
implementacin de una dependencia a otra (como en el ejemplo de Hibernate que
mencion antes)
Las dependencias se manejan en un solo lugar: Toda la informacin de dependencias
es responsabilidad de un solo componente, el contenedor de IoC de Spring, haciendo
que este manejo de dependencias ms simple y menos propenso a errores.
Hace que las pruebas sean ms fciles: Nuevamente, como nuestras clases sern
diseadas para que sea fcil el reemplazo de dependencias, podemos proporcionar
mocks o dummies, que regresen datos de prueba, de servicios o cualquier
dependencia que necesite el componente que estamos probando.
Como podemos ver, el uso de DI nos proporciona muchos beneficios, pero no sin sus
correspondientes desventajas. En particular, es difcil ver qu implementacin
particular de una dependencia est siendo usada para qu objeto, especialmente para
alguien que no est familiarizado con esta forma de trabajo.
Spring est dividido en alrededor de 20 mdulos y colocados en los siguientes grupos:
Contenedor Central (Core Container)

Acceso a Datos / Integracin
WEB
AOP (Programacin Orientada a Aspectos)
Instrumentacin
Pruebas
Estos grupos se muestran en la siguiente imagen:
CIBERTEC
160
Inyeccin de dependencias mediante constructor

En el siguiente ejemplo, podemos ver como el objeto declara sus dependencias en el
constructor. Podemos observar que no hay cdigo que se encargue de buscar esa
dependencia o crearla, simplemente la declara. Esto nos ayuda a tener clases Java
mucho ms limpias a la vez que ayuda a facilitar el Testing, ya que, en un entorno de
Tests, podramos intercambiar ese objeto por un Mock sin cambiar el cdigo (mediante
la configuracin de Spring).
Para informar a Spring de cul es la dependencia que tiene que inyectar en

GeneradorPlaylist, podemos hacerlo mediante XML o anotaciones. En el siguiente
ejemplo, vamos a ver como se configurara mediante XML:
Inyeccin de dependencias mediante "Setter"

Spring, tambin, permite inyectar la dependencia mediante los Setter (mtodos set*()).
Cada forma de inyectar las dependencias tiene sus ventajas y sus desventajas,
aunque la mayora de los desarrolladores prefiere inyectar las dependencias mediante
los mtodos Set.
Para indicarle a Spring qu queremos que inyecte la dependencia, podemos hacerlo
mediante anotaciones o XML. Vamos a ver cmo sera mediante anotaciones.
Mediante la anotacin @autowired, le indicamos a Spring que se tiene que encargar

de buscar un Bean que cumpla los requisitos para ser inyectado. En este caso, el
nico requisito es que sea del tipo BuscadorCanciones. En caso de que hubiese ms
CIBERTEC
161
de un Bean que cumpliese esos requisitos, tendramos que decirle a Spring cul es el
Bean correcto.
3.1.2. Arquitectura
Spring podra potencialmente ser nica para todas sus aplicaciones empresariales, sin
embargo, Spring es modular, lo que le permite seleccionar y elegir los mdulos que se
aplican a usted, sin tener que poner el resto. Despus de la seccin da detalles acerca
de todos los mdulos disponibles en Spring Framework.
El Spring Framework proporciona cerca de 20 mdulos que se pueden utilizar en base
a los requisitos establecidos.
Contenedor Core:
El Core Container consiste en el Core, Beans, Contexto y mdulos de lenguaje de
expresin cuyo detalle es el siguiente:
El mdulo Core proporciona las partes fundamentales de la estructura, incluyendo las
caractersticas de inyeccin COI y de dependencia.
El mdulo bean proporciona BeanFactory que es una sofisticada implementacin del
patrn de fbrica.
El mdulo de contexto se basa en la slida base proporcionada por los mdulos del
ncleo y Frijoles y es un medio para acceder a los objetos definidos y configurados. La
interfaz ApplicationContext es el punto central del mdulo de contexto.
El mdulo de lenguaje de expresin proporciona un poderoso lenguaje de expresin
para consultar y manipular un grfico de objetos en tiempo de ejecucin.
CIBERTEC
162
Acceso a datos / integracin:

La capa de acceso a datos / integracin consiste en la JDBC, ORM, OXM, JMS y
mdulos de transaccin cuyo detalle es el siguiente:
El mdulo de JDBC proporciona una capa de abstraccin JDBC-que elimina la
necesidad de hacer JDBC tedioso codificacin relacionada.
El mdulo ORM provee capas de integracin para APIs de mapeo objeto-relacional
populares, incluyendo JPA, JDO, Hibernate, y iBatis.
El mdulo de OXM ofrece una capa de abstraccin que soporta implementaciones de
mapeo objeto / XML para JAXB, Castor, XMLBeans, JiBX y xstream.
El mdulo de servicio de mensajera Java JMS contiene caractersticas para producir
y consumir mensajes.
El mdulo de Transaction apoya la gestin de transacciones programticas y
declarativas de clases que implementan interfaces especiales y para todos tus POJOs.
Web:
La capa Web consiste en la Web, mdulos Web-portlet cuyo detalle es el siguiente
Web-Servlet, Web-Struts, y:
El mdulo Web proporciona funciones de integracin bsicas de web como la
funcionalidad de carga de archivos de varias partes y la inicializacin del contenedor
IoC usando oyentes servlet y un contexto de aplicacin orientado a la web.
El mdulo Web-Servlet contiene el modelo-vista-controlador (MVC) la ejecucin de la
primavera para las aplicaciones web.
El mdulo Struts contiene las clases de apoyo para la integracin de una capa web
Struts clsicos dentro de una aplicacin de Spring.
El mdulo Portlets proporciona la implementacin MVC para ser utilizado en un
entorno de mdulo de funcin y refleja la funcionalidad del mdulo de Web-Servlet.
Varios:
Hay algunos otros mdulos importantes como AOP, Aspectos, Instrumentacin,
mdulos Web y de color cuyo detalle es el siguiente:
El mdulo de AOP ofrece implementacin de programacin orientada a aspectos que
le permite definir el mtodo-interceptores y puntos de corte para desvincular
limpiamente cdigo que implementa la funcionalidad que debe ser separada.
El mdulo Aspectos proporciona integracin con AspectJ que es otra vez un marco de
programacin potente y madura aspecto orientado (AOP).
El mdulo de Instrumentacin proporciona clases y las implementaciones de
cargador de clases que se utilizan en ciertos servidores de aplicaciones.
El mdulo de Test apoya la prueba de los componentes de Spring con frameworks
JUnit o TestNG.
CIBERTEC
163
Resumen
1. El mdulo ORM provee capas de integracin para APIs de mapeo objetorelacional populares, incluyendo JPA, JDO, Hibernate, y iBatis.
2. El mdulo de AOP ofrece implementacin de programacin orientada a aspectos
que le permite definir el mtodo-interceptores y puntos de corte para desvincular
limpiamente cdigo que implementa la funcionalidad que debe ser separada.
unidad:
Spring-Arquitectura: http://www.tutorialspoint.com/spring/spring_architecture
CIBERTEC
164
3.2. SPRING WEB

3.2.1. Introduccin
El framework (MVC) modelo-vista-controlador Spring Web est diseado en torno a un
DispatcherServlet que enva solicitudes a los handlers, con signaciones de controlador
configurable, vista la resolucin, localidad, zona horaria y la resolucin de tema, as
como soporte para cargar archivos. El controlador predeterminado se basa en
@Controller y @RequestMapping, ofreciendo una amplia gama de mtodos de
manipulacin flexibles. Con la introduccin de Spring 3.0, el @Controller tambin le
permite crear sitios Web REST full Web y aplicaciones, a travs de las anotaciones
@PathVariable
y
otras
caractersticas.
Springs view es extremadamente flexible. Un controlador es normalmente responsable

de la preparacin de un mapa modelo con los datos y la seleccin de un nombre de la
vista, pero tambin puede escribir directamente en la secuencia de respuesta y
completar la solicitud. Resolucin de nombre de vista es altamente configurable a travs
de la extensin de archivo o Aceptar tipo de contenido de encabezado de negociacin, a
travs de nombres de los beans, un archivo de propiedades, o incluso una aplicacin
ViewResolver personalizado. El modelo (M en la MVC) es un Map de interfce, que
permite la abstraccin completa de la tecnologa de vista. Usted puede integrar
directamente con las tecnologas de representacin de la plantilla basada como JSP,
Velocity y Freemarker, o directamente generar XML, JSON, Atom, y muchos otros tipos
de contenido. El modelo Map simplemente se transforma en un formato apropiado, tal
como atributos de la peticin JSP, un modelo de Velocity Template.
3.2.2. Configuracin
Debido a la explosin de las aplicaciones mviles cada da nos encontramos con una
mayor necesidad de utilizar frameworks web que generen paginas HTML sencillas de tal
forma que luego puedan decorarse con otras tecnologas tipo Bootstrap ,JQuery mobile
o similares. A este tipo de categora pertenece el framework Spring MVC que cada da
es ms utilizado en las empresas. La siguiente comparativa es interesante para ver que
cuota de mercado tiene cada framework.
Como podemos ver, aunque JSF es el standard Spring MVC, hoy por hoy, es el
framework web ms utilizado. Recordemos que un modelo de FrontController funciona
de la siguiente manera:
CIBERTEC
165
pom.xml
</pre>
<dependencies>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-servlet_3.0_spec</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.2.4.RELEASE</version>
</dependency>
<dependency>
<artifactId>spring-webmvc</artifactId>
</dependency>
</dependencies>
<pre>
Realizado este paso, se configura el framework Spring dentro de nuestra aplicacin

web. Para ello, deberemos aadir el siguiente bloque de cdigo en nuestro web.xml.
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<display-name>Spring MVC</display-name>
<servlet>
<servlet-name>springmvc</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/application-context.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springmvc</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
</web-app>
El fichero web.xml da de alta un nuevo servlet denominado DispatcherServlet que es el

que realiza las tareas de controlador frontal de la aplicacin y captura todas las
peticiones ya que su url-pattern es /. Este controlador se apoya en el fichero clsico de
Spring Framework que se encargar de gestionar los distintos flujos de la aplicacin a
traves del uso de beans.
CIBERTEC
166
El cdigo del fichero application-context.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">
<bean name="/Lista"
class="com.arquitecturajava.ListaController"/>
<bean name="/Formulario"
class="com.arquitecturajava.FormularioController"/>
</beans>
En nuestro caso, vamos a optar por un primer ejemplo muy bsico que usa dos beans
que gestionan las distintas urls a las que accedemos utilizando el patrn MVC2.
En estas dos clases, veremos lo siguiente:
Cdigo ListaController:
package com.arquitecturajava;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.Controller;
CIBERTEC
167
public class ListaController implements Controller {

public ModelAndView handleRequest (HttpServletRequest request,
HttpServletResponse response) throws Exception {
return new ModelAndView("/WEB-INF/jsp/Lista.jsp");
}
}
Cdigo Formulario Controller :

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.Controller;
public class FormularioController implements Controller {
public ModelAndView handleRequest (HttpServletRequest request,
HttpServletResponse response) throws Exception {
return new ModelAndView("/WEB-INF/jsp/Formulario.jsp");
}
}
Como podemos ver, nuestras clases implementan el interface Controller y tienen un

mtodo muy similar al mtodo ejecutar (handleRequest) que nos redirige a una URL en
concreto.
Una vez que tenemos claro cmo funcionan los controladores que hemos definido es
momento de ver el contenido de los ficheros JSP a los que hacen referencia. Lista.jsp
</pre>
<html>
<head>
CIBERTEC
168
<meta http-equiv="Content-Type" content="text/html; charset=UTF8">

<title>Lista de Personas</title>
</head>
<body>
<ul>
<li>Pedro</li>
<li>Maria</li>
</ul>
<a href="Formulario">Ir a formulario</a>
</body>
</html>
<pre>
Formulario.jsp
</pre>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF8">
</head>
<body>
<form action="Lista">
Nombre<input type="text" name="nombre" /></br>
Apellidos<input type="text" name="apellidos" /></br>
<input type="submit" value="Aceptar"/>
</form>
</body>
</html>
<pre>
Si solicitamos la url /Lista Spring MVC, nos devolver el contenido el fichero Lista.jsp.
Spring MVC Anotaciones

Se muestra en este ejemplo anotaciones de Spring. Lo primero que vamos a hacer es
aadir un ViewResolver a nuestro fichero application-context.xml.
<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolv
er">
<property name="prefix" value="/WEB-INF/jsp/" />
<property name="suffix" value=".jsp" />
</bean>
CIBERTEC
169
Se trata de un bean sencillo que parametriza la URL de las distintas vistas que
cargamos. A partir de este momento, nuestros controladores podrn devolver algo
como lo siguiente:
return new ModelAndView ("Lista");
Spring MVC y @Controller

A partir de Spring 2.5, se permite el uso de un sistema de anotaciones que simplifica la
forma de trabajar. Para usar este sistema, deberemos, en primer lugar, aadir una
nueva dependencia a nuestro pom.xml.
<dependency>
<artifactId>spring-context</artifactId>
</dependency>
Esta dependencia nos permitir modificar el fichero application-context.xml y aadir

una etiqueta
<context:component-scan base-package="com.arquitecturajava"/>
Esta etiqueta se encarga de decirle a Spring en qu packages debe buscar clases

anotadas para su registro. En nuestro caso, en com.arquitecturajava, una vez
realizada esta operacin, creamos una clase PersonaController dentro del package.
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
public class PersonaController {
@RequestMapping("/Lista")
public String Lista() {
return "Lista";
}
@RequestMapping("/Formulario")
public String Formulario() {
return "Formulario";
}
}
Disponemos de un controlador que agrupa un conjunto de acciones.
CIBERTEC
170
@Controller: Anotacin que registra el controlador para Spring MVC

@RequestMapping: Anotacin que se encarga de relacionar un mtodo con una
peticin http.
El uso de anotaciones no implica que nicamente tengamos un nico controlador sino
que nos permite agrupar un conjunto de urls que estn asociadas a nivel de negocio
en un controlador especfico. La aplicacin soportar n controladores.
Spring MVC y el Modelo

Por ahora, lo nico que hemos hecho es construir el controlador. Luego, el controlador
suele enviar datos a la vista a travs de un modelo. Vamos a modificar
PersonaController para que tenga una lista de Personas y nos las enve a Lista.jsp. El
primer paso ser aadir la clase Persona.
public class Persona {
private String nombre;
private String apellidos;
public Persona(String nombre, String apellidos) {
CIBERTEC
171
super();
this.nombre = nombre;
this.apellidos = apellidos;
}
//omitimos equals y hashcode eclipse
public String getNombre() {
return nombre;
}
public void setNombre(String nombre) {
this.nombre = nombre;
}
public String getApellidos() {
return apellidos;
}
public void setApellidos(String apellidos) {
this.apellidos = apellidos;
}
}
Realizada esta operacin, el siguiente paso ser modificar el controlador para que
genere una lista de Personas.
import
import
import
import
import
java.util.ArrayList;
java.util.List;
org.springframework.stereotype.Controller;
org.springframework.ui.Model;
org.springframework.web.bind.annotation.RequestMapping;
@Controller
public class PersonaController {
@RequestMapping("/Lista")
public String Lista(Model modelo) {
List<Persona> milista= new ArrayList<Persona>();
Persona persona1= new Persona ("pedro","perez");
Persona persona2=new Persona ("mara","gonzalez");
milista.add(persona1);
milista.add(persona2);
modelo.addAttribute("listaPersonas",milista);
return "Lista";
}
@RequestMapping("/Formulario")
public String Formulario() {
return "Formulario";
}
}
Como podemos observar, ahora, el mtodo lista soporta un objeto de tipo Model. Es
en este objeto en el cual nosotros aadimos la lista. Realizado este paso, nos quedar
modificar la pgina JSP para que nos muestre una lista utilizando JSTL. Para ello,
antes deberemos aadir la dependencia a Maven.
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
CIBERTEC
172
</dependency>
Finalmente, mostramos la pgina JSP que se encarga de mostrar la lista de personas.

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<ul>
<c:forEach items="${listaPersonas}" var="persona">
<li>${persona.nombre}, ${persona.apellidos}</li>
</c:forEach>
</ul>
<a href="Formulario">Ir a formulario</a>
</body>
</html>
Para finalizar, cargamos la pgina en un navegador y nos mostrar la lista.
CIBERTEC
173
Resumen
1. @Controller: Anotacin que registra el controlador para Spring MVC
2. @RequestMapping: Anotacin que se encarga de relacionar un mtodo con una

peticin http.
unidad:
Spring web: http://docs.spring.io/spring/docs/current/spring-frameworkreference/html/mvc.htmlXX:
CIBERTEC
174
3.3. SPRING MDULOS

3.3.1. Spring security
La aplicacin construida se debe configurar para que quede protegida por Spring
Security. Para ello, el primer paso que debemos realizar es dar de alta en el fichero
web.xml la ruta en donde tenemos ubicado el fichero de configuracin de Spring.
Una vez que tenemos configurado el fichero web.xml, el filtro de SpringSecurity se

encargar de bloquear el acceso a toda la aplicacin.
CIBERTEC
175
Vamos a ver el cdigo fuente del web.xml para clarificar dudas:

web.xml
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
<display-name>web01</display-name>

<context-param>
<param-value>
/WEB-INF/springSecurity.xml
</param-value>
</context-param>

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
SpringSecurity.xml

<bean:beans xmlns:bean="http://www.springframework.org/schema/beans"
xmlns="http://www.springframework.org/schema/security"
CIBERTEC
176
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security3.2.xsd">
<http auto-config="true">
<intercept-url pattern="/**" access="ROLE_Usuario" />
</http>
<authentication-manager>
<authentication-provider>
<user-service>
<user name="manuel" password="1234" authorities="ROLE_Usuario" />
</user-service>
</authentication-provider>
</authentication-manager>
</bean:beans>
El fichero define varios conceptos fundamentales:

El grupo de recursos protegidos (URLs)
<http auto-config="true">
<intercept-url pattern="/**" access="ROLE_Usuario" />
</http>
En este caso, est toda la aplicacin protegida /** y solo se permite el acceso al role
ROLE_Usuario.
AutenticationManager o gestor de autentificacin que decide cuando un usuario
es vlido. Este gestor est ntimamente relacionado con el concepto de
AutenticationProvider o proveedor de autentificacin.
<authentication-manager>
<authentication-provider>
<user-service>
</user-service>
</authentication-provider>
Este ltimo el AutenticationProvider define la forma en la que un usuario se ha

de validar. Puede ser contra una base de datos, puede ser contra un Ldap, puede ser
contra un fichero o puede personalizarse. En nuestro caso, estamos utilizando un
servicio en memoria que solo permite el acceso al siguiente usuario.
CIBERTEC
177
El siguiente diagrama clarifica la relacin entre los elementos.
Realizada esta operacin, ejecutamos maven package y nos empaquetar la

aplicacin de tal forma que si la desplegamos en un servidor (Tomcat por ejemplo) e
intentamos acceder a la pgina de bienvenidos, Spring Security nos bloquear el
acceso y mostrar la siguiente pantalla.
Introducimos de usuario manuel y de clave 1234, y el framework nos dar acceso a la
pgina protegida.
CIBERTEC
178
CIBERTEC
179
Resumen
1. Puede agregar, en el web.xml, el parmetro del archivo de configuracin del
Security.
<context-param>
<param-value>
/WEB-INF/springSecurity.xml
</param-value>
</context-param>
2. Tambin, puede agregar el siguiente Filtro.

<filter>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
unidad:
Adictos al trabajo:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introSpring
Security
Download Spring Security: http://projects.spring.io/spring-security/
CIBERTEC

Manual 2015-I 06 Proyecto Empresarial (CI) (0780)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual 2015-I 06 Proyecto Empresarial (CI) (0780)

Cargado por

Copyright:

Formatos disponibles

Proyecto

CARRERA DE COMPUTACIN E INFORMTICA

JAVA PERSISTENCE API

OR-Mapping con JPA

Relaciones entre entidades

The Java Persistence Query Language.

CARRERA DE COMPUTACIN E INFORMTICA

2.2 Tema 6 : Componentes de Interfaz de usuario

2.3 Tema 7 : Conversiones, Validaciones y Eventos

Integracin JSF y JPA

3.2 Tema 10 : Spring Web

3.3 Tema 11 : Spring Mdulos

CARRERA DE COMPUTACIN E INFORMTICA

El curso de Proyecto Empresarial pertenece a la lnea de Programacin dentro de la

CARRERA DE COMPUTACIN E INFORMTICA

CARRERA DE COMPUTACIN E INFORMTICA

CARRERA DE COMPUTACIN E INFORMTICA

CARRERA DE COMPUTACIN E INFORMTICA

Introduccin al API de Persistencia JPA

OR-Mapping con JPA

Relaciones entre entidades

CARRERA DE COMPUTACIN E INFORMTICA

The Java Persistence Query Language.

Reconocer las clases de la API Persistencia JPA

CARRERA DE COMPUTACIN E INFORMTICA

CARRERA DE COMPUTACIN E INFORMTICA

1.1. INTRODUCCIN AL API DE PERSISTENCIA JPA

Persistencia: las entidades pueden ser manipuladas para recuperase en

Una copia del documento se puede obtener en el enlace:

CARRERA DE COMPUTACIN E INFORMTICA

Identidad: significa que las entidades tienen un identificador que permite

Transaccionalidad: Todas las operaciones (insertar, modificar o eliminar)

Granularidad: Las entidades son objetos que pertenecen a un dominio de

Las anotaciones fueron introducidas en la versin JAVA EE 5 y permiten que la

Se puede convertir en entidad, simplemente agregndole las anotaciones:

CARRERA DE COMPUTACIN E INFORMTICA

FUENTE: JPA 2: Mastering the Java Persistence API, pg 23.

CARRERA DE COMPUTACIN E INFORMTICA

Un Entity Manager se obtiene de la siguiente forma:

Variable con el Entity Manager cargado

1.1.4. Unidad de Persistencia

CARRERA DE COMPUTACIN E INFORMTICA

Debido a que es un archivo XML, debe tener un DTD:

Luego, viene la definicin de la Unidad de persistencia, el proveedor y las clases Java

El valor de RESOURCE_LOCAL indica que la conexin a la base de datos se realizar

CARRERA DE COMPUTACIN E INFORMTICA

Finalmente se cierran los tags XML:

Observe que las propiedades JDBC (javax.persistence.jdbc.*) han sido estandarizadas

1.1.5. Operaciones bsicas

SQL INSERT = Mtodo Persist

SQL SELECT = Mtodo Find ( o tambin puede usarse el SELECT JPQL )

SQL UPDATE = Mtodo Merge

SQL DELETE = Mtodo Remove

El persist de una entidad significa crear un objeto en memoria y luego almacenarlo

Se ejecuta el mtodo persist

CARRERA DE COMPUTACIN E INFORMTICA

variable con el EntityManager cargado

Si la entidad con la llave primara indicada no existe, el EntityManager devolver NULL.

Se requiere cargar la entidad

Como se mencion anteriormente, si la entidad no existe el EntityManager devolver

Para actualizar atributos de una entidad, se emplea el mtodo merge. Se requiere

En este ejemplo, se est actualizando el apellido del empleado con ID = 8.

CARRERA DE COMPUTACIN E INFORMTICA

Se inicia una transaccin