Ejemplo JSF2.0+Spring Web+Spring Security+hibernate+richfaces4

Example Using Multiple Java EE 6 Technologies with RichFaces.
This application builds on top of the standard JSF approach by incorporating the RichFaces project to provide a set of components, allowing for a rich user experience.
RichFaces builds on top of the JSF standard and is a fully portable solution compatible with all JSF implementations.
System requirements -------------------
All you need to build this project is Java 6.0 (Java SDK 1.6) or better, Maven 3.0 or better.

 4.0.0

 org.jboss.tools.example.richfaces
 demo2
 0.0.1-SNAPSHOT
 war
 Mantendeor Personal SIEP
 A starter Java EE 6 webapp project for use generated from the richfaces-archetype-kitchensink archetype

 http://jboss.org/richfaces

 
  
  
  UTF-8
  
  1.0.0.Final
  
  
  4.2.2.Final
  3.0.5.RELEASE
 

 
  
   
    org.richfaces
    richfaces-bom
    ${org.richfaces.bom.version}
    pom
    import
   
  
 

 
  
   javax
   javaee-api
   6.0
  
  
   org.hibernate.javax.persistence
   hibernate-jpa-2.0-api
   1.0.1.Final
  
  
   org.hibernate
   hibernate-entitymanager
   4.2.0.Final
  
  
   org.hibernate
   hibernate-validator
   4.2.0.Final
   provided
   
    
     org.slf4j
     slf4j-api
    
   
  

  
  
   org.jboss.spec.javax.faces
   jboss-jsf-api_2.1_spec
   provided
  

  
  
   org.jboss.spec.javax.servlet
   jboss-servlet-api_3.0_spec
   provided
  

  
  
   org.richfaces.core
   richfaces-core-impl
   
    
     guava
     com.google.guava
    
   
  
  
  
   org.richfaces.ui
   richfaces-components-ui
  

  
  
   org.atmosphere
   atmosphere-runtime
   
    
     org.slf4j
     slf4j-api
    
   
  

  

  
  
   org.hibernate
   hibernate-jpamodelgen
   1.2.0.Final
   provided
  

  
  
   org.ocpsoft.rewrite
   rewrite-servlet
  

  
  
   org.ocpsoft.rewrite
   rewrite-integration-cdi
  

  
  
   junit
   junit
   4.10
  
  
   org.springframework
   spring-core
   ${org.springframework.version}
  
  
   org.springframework
   spring-orm
   ${org.springframework.version}
  
  
   org.springframework
   spring-web
   ${org.springframework.version}
  

  
   org.springframework
   spring-expression
   ${org.springframework.version}
  

  
   org.springframework.security
   spring-security-core
   3.1.2.RELEASE
  

  
   org.springframework.security
   spring-security-web
   3.1.2.RELEASE
  

  
   org.springframework.security
   spring-security-config
   3.1.2.RELEASE
  

  
   org.springframework.security
   spring-security-ldap
   3.1.2.RELEASE
  

  
   org.springframework.ldap
   spring-ldap-core
   1.3.1.RELEASE
  

  
   org.springframework.ldap
   spring-ldap-core-tiger
   1.3.1.RELEASE
  

  
   org.springframework.ldap
   spring-ldap-odm
   1.3.1.RELEASE
  

  
   org.springframework.ldap
   spring-ldap-ldif-core
   1.3.1.RELEASE
  

  
   org.springframework.ldap
   spring-ldap-ldif-batch
   1.3.1.RELEASE
  

 

 
  
  ${project.artifactId}
  
   
   
    maven-compiler-plugin
    2.3.2
    
     1.7
     1.7
    
   
   
    maven-war-plugin
    2.1.1
    
     
     false
     
      
       com.google.guava,org.slf4j
      
     
    
   
  
 

 
  
   default
   
    true
   
   
    
     
      maven-surefire-plugin
      2.10
      
       true
      
     
    
   
  
  
   openshift
   
    
     
      maven-war-plugin
      
       deployments
       ROOT
      
     
    
   
  

 

Esquema conceptual de APIS utilizadas:

Uso de APIS de Spring:

Capa de datos:

 
  Base De Desarrollo
  org.hibernate.ejb.HibernatePersistence
  jdbc/MantenedorPU
  cl.sernapesca.siep.entities.Log
  cl.sernapesca.siep.entities.Oficina
  cl.sernapesca.siep.entities.Persona
  cl.sernapesca.siep.entities.Region
  
   
   
   
   
   
   
   
   
   
  
 

Capa de datos:

JPA y Administración de transacciones
Es importante notar que la APP en sí mismo no proporciona ningún tipo de gestión de transacciones declarativa. Al usar JPA fuera de un contenedor de inyección de dependencias, las transacciones deben ser manejados pro-gramáticamente por el desarrollador:
Mediante el uso de @Transactional , muchos aspectos importantes, como la propagación de transacciones se manejan automáticamente. En este caso, si otro método transaccional es llamado por businessLogic() , este método tendrá la opción de unirse a la transacción en curso.
Una desventaja potencial es que este poderoso mecanismo oculta lo que está pasando debajo de la Capa de datos, por lo que es difícil de depurar cuando las cosas no funcionan.
¿Qué @Transactional significa?
Uno de los puntos clave sobre @Transactional es que hay dos conceptos distintos a considerar, cada uno con su propio ciclo alcance y la vida: el contexto de persistencia base de datos de la transacción

La misma anotación transaccional define el alcance de una sola transacción de base de datos. La transacción de base de datos que sucede dentro del ámbito de un contexto de persistencia.
El contexto de persistencia JPA está en el EntityManager , implementado internamente usando un Hibernate Session (cuando se utiliza Hibernate como proveedor de persistencia).
El contexto de persistencia es sólo un objeto sincronizador que rastrea el estado de un conjunto limitado de objetos Java y se asegura de que los cambios en esos objetos son finalmente persistieron de nuevo en la base de datos.
Esta es una noción muy diferente que el de una transacción de base de datos. Un Gerente de la Entidad se puede utilizar la mayoría de las transacciones de bases de datos, y que en realidad a menudo es. Cuando hace un transacciones de bases de datos múltiples EntityManager envergadura?
El caso más frecuente es cuando la aplicación está utilizando la Sesión Abierta Ver la pauta para hacer frente a las excepciones de inicialización perezosa.
En tal caso, las consultas que se ejecutan en la capa de vista están en las transacciones de bases de datos separadas que el utilizado para la lógica de negocio, sino que se realizan a través del mismo gestor de la entidad.
Otro caso es cuando el contexto de persistencia está marcado por el desarrollador como PersistenceContextType.EXTENDED , lo que significa que puede sobrevivir múltiples peticiones.
Lo que define el EntityManager vs relación de transacción?
Esto es realmente una elección de los desarrolladores de aplicaciones, pero la forma más frecuente de utilizar el Administrador de JPA Entidad es con el "Administrador de la Entidad por transacción aplicación" patrón. Esta es la forma más común de inyectar un gestor de entidades

package cl.sernapesca.siep.dao.impl;

import java.util.List;

import javax.persistence.EntityManagerFactory;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.orm.jpa.support.JpaDaoSupport;
import org.springframework.stereotype.Repository;

import cl.sernapesca.siep.dao.IOficinaDao;
import cl.sernapesca.siep.entities.Oficina;

@Repository
public class JPAOficinaDao extends JpaDaoSupport implements IOficinaDao {
 
 @Autowired
    public JPAOficinaDao(EntityManagerFactory entityManagerFactory)
    {
        setEntityManagerFactory(entityManagerFactory);
    }
 
 @SuppressWarnings("unchecked")
 @Override
 public List findOficinaAll() {
  try {
   List results = getJpaTemplate().find("select o from Oficina o");
   System.out.println("Size findOficinaAll" + results.size());
   return results;
  } catch (Exception e) {
   System.out.println(e.getMessage());
   return null;
  }
 }
 
 @Override
 public Oficina findOficinaByCodigo(Integer codigo) {
  try {
   return getJpaTemplate().find(Oficina.class, codigo);
  } catch (Exception e) {
   System.out.println(e.getMessage());
   return null;
  }
 }
 @SuppressWarnings("unchecked")
 @Override
 public List findOficinaByCodigoRegion(Integer codigoRegion) {
  try {
   return getJpaTemplate().find("select o from Oficina o where o.region.codigo = ?1", codigoRegion);
  } catch (Exception e) {
   System.out.println(e.getMessage());
   return null;
  }
 }
 

 @Override
 public boolean updateOficina(Integer codigo) {
  // TODO Auto-generated method stub
  return false;
 }

}

¿Qué es un Administrador de transacciones?
Gestores de transacciones en Spring
Un gestor de transacciones es la parte de una aplicación que se encarga de coordinar las transacciones a través de uno o más recursos. En el marco Spring, el gestor de transacciones es efectivamente la raíz del sistema de transacción. Por lo tanto, si desea habilitar las transacciones en un componente en SPRING, normalmente se crea un gestor de beans de transacción y pasarlo al componente.
Las responsabilidades del administrador de transacciones son las siguientes:
Demarcación que empiezan y finalizando transacciones utilizando empezar, comprometerse, y los métodos de rollback.
Administrar el contexto contexto de transacción -a transacción contiene la información que un gestor de transacciones necesita para realizar un seguimiento de una transacción.
El gestor de transacciones es responsable de crear contextos de transacción y adjuntarlos al hilo actual.
La coordinación de la transacción a través de múltiples recursos gestores de transacciones a nivel -Enterprice suelen tener la capacidad para coordinar una transacción a través de múltiples recursos. Esta función requiere la 2 fase protocolo de confirmación y recursos debe estar registrado y gestionado utilizando el protocolo XA (ver X / estándar abierto XA ).
Esta es una función avanzada, no soportado por todos los administradores de transacciones.
La recuperación de los gestores -transaction fallo son responsables de asegurar que los recursos no se queden en un estado incoherente, si hay una falla en el sistema y la aplicación se bloquea.
 En algunos casos, la intervención manual puede ser necesaria para restaurar el sistema a un estado coherente.

Flujo de transacciones usando Spring Data:

Gestores de transacciones locales(el ejemplo esta basado para WEBLOGIC)
Un administrador de transacciones locales es un gestor de transacciones que se pueden coordinar las transacciones sobre un solo recurso.
En este caso, la aplicación de la gestor de transacciones es típicamente incrustado en el mismo y el gestor de transacciones del resorte de recursos es sólo una envoltura fina alrededor de este gestor de transacciones incorporado.

Por ejemplo, la base de datos Oracle tiene un gestor integrado de transacción que apoya las operaciones de demarcación (mediante operaciones de SQL, BEGIN , COMMIT , ROLLBACK , o el uso de una API nativa de Oracle) y varios niveles de aislamiento de transacción. El control sobre el administrador de transacciones de Oracle se puede exportar a través de JDBC, que es como SPRING es capaz de envolver este gestor de transacciones.
Es importante entender lo que constituye un recurso, en este contexto.
 Por ejemplo, si usted está usando un producto de JMS, el recurso JMS es la instancia en ejecución única del producto JMS, no las colas y los temas individuales. Por otra parte, a veces, lo que parece ser múltiples recursos podrían ser en realidad un único recurso, si se accede al mismo recurso subyacente de diferentes maneras.
Por ejemplo, su aplicación puede acceder a una base de datos relacional, tanto directamente (a través de JDBC) e indirectamente (a través de una herramienta de mapeo objeto-relacional como Hibernate).
En este caso, el mismo gestor de transacción subyacente está implicado, por lo que debería ser posible inscribir a ambos de estos fragmentos de código en la misma transacción.

[Nota] Nota
No se puede garantizar que esto va a funcionar en todos los casos. Aunque es posible, en principio, con cierto detalle en el diseño del marco de SPRING u otras capas de envoltura podría impedir que funcione en la práctica.

Por supuesto, es posible que una aplicación tiene muchos diferentes gestores de transacciones locales que trabajan de forma independiente el uno del otro.

Por ejemplo, usted podría tener una ruta que manipula colas JMS y temas, en los que los puntos finales JMS hacen referencia a un gestor de transacciones JMS. Otra ruta podría acceder a una base de datos relacional a través de JDBC.
Pero no se puede combinar JDBC y JMS de acceso en la misma ruta y hacer que ambos participan en la misma transacción.

Gestores de transacciones globales

Un administrador de transacciones global es un gestor de transacciones que se pueden coordinar las transacciones a través de múltiples recursos.
 En este caso, no se puede confiar en el administrador de transacciones integrado en el propio recurso.
En lugar de ello, se necesita un sistema externo, a veces llamado un monitor de procesamiento de transacciones (supervisor de TP), que es capaz de coordinar las transacciones a través de diferentes recursos.

Flujo de transacciones globales de WEBLOGIC:

Los siguientes son los requisitos previos para transacciones globales:

Administrador de transacciones internacionales o supervisor de TP sistema de transacción externa -una que implementa el 2 fases comprometen protocolo para coordinar múltiples recursos XA.
Recursos que apoyan el estándar XA -en fin de participar en una fase 2 se comprometen, los recursos deben ser compatibles con el estándar / Open XA X . En la práctica, esto significa que el recurso es capaz de exportar un objeto conmutador XA, que le da el control total de las transacciones con el supervisor de TP externo.
[Consejo] Consejo
El marco de Spring no proporcionan por sí mismo un monitor TP para gestionar las transacciones globales. Lo hace, sin embargo, proporciona soporte para la integración con un supervisor de TP-OSGi proporcionado o con un supervisor de TP-J2EE proporcionado (donde la integración se lleva a cabo por el JtaTransactionManager clase). Por lo tanto, si implementa la aplicación en un contenedor OSGi con el apoyo total de transacciones, puede utilizar múltiples recursos transaccionales en Spring.

Gestores de transacciones distribuidas

Por lo general, un servidor se conecta directamente a los recursos que intervienen en una transacción. En un sistema distribuido, sin embargo, a veces es necesario para conectarse a los recursos que están expuestos de manera indirecta, a través de un servicio web o por medio de una interfaz CORBA IDL. En este caso, se requiere un supervisor de TP que es capaz de soportar transacciones distribuidas. Varias normas están disponibles que describen la forma de apoyar las operaciones de varios protocolos distribuidos, por ejemplo, la WS-AtomicTransactions especificación para servicios Web y el servicio de transacciones CORBA Object (OTS) especificación para aplicaciones CORBA.

[Nota] Nota
Gestores de transacciones distribuidas se encuentran fuera del alcance de Apache Camel y el marco de Spring.

package cl.sernapesca.siep.dao;

import java.util.List;

import cl.sernapesca.siep.entities.Oficina;

public interface IOficinaDao {

 public List findOficinaAll();
 public List findOficinaByCodigoRegion(Integer codigoRegion);
 public Oficina findOficinaByCodigo(Integer codigo);
 
 public boolean updateOficina(Integer codigo);
}

package cl.sernapesca.siep.dto;


public class OficinaDto {
 
 private Integer codigo;
 private String nombre;
 private Integer codigo_oficina_region;
 private Integer códigoRegion;
 private String nombreRegion;

 public Integer getCodigo() {
  return codigo;
 }

 public void setCodigo(Integer codigo) {
  this.codigo = codigo;
 }

 public String getNombre() {
  return nombre;
 }

 public void setNombre(String nombre) {
  this.nombre = nombre;
 }

 public Integer getCodigo_oficina_region() {
  return codigo_oficina_region;
 }

 public void setCodigo_oficina_region(Integer codigo_oficina_region) {
  this.codigo_oficina_region = codigo_oficina_region;
 }

 public Integer getCódigoRegion() {
  return códigoRegion;
 }

 public void setCódigoRegion(Integer códigoRegion) {
  this.códigoRegion = códigoRegion;
 }

 public String getNombreRegion() {
  return nombreRegion;
 }

 public void setNombreRegion(String nombreRegion) {
  this.nombreRegion = nombreRegion;
 }
}

package cl.sernapesca.siep.entities;

import java.io.Serializable;
import java.util.List;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
import javax.persistence.OneToMany;
import javax.persistence.Table;


@Entity
@Table(name = "tb_oficina")
public class Oficina implements Serializable {

 @Id
 @Column(name = "Cd_Oficina", unique = true, nullable = false)
 private Integer codigo;

 @Column(name = "Nm_Oficina", nullable = false, length = 20)
 private String nombre;
 
 @Column(name="Cd_OfiRegion", nullable = false)
 private Integer Cd_OfiRegion;

 @ManyToOne(fetch = FetchType.EAGER)
 @JoinColumn(name = "Cd_Region")
 private Region region;

 @OneToMany(mappedBy = "oficina")
 private List personas;

 public Integer getCodigo() {
  return codigo;
 }

 public void setCodigo(Integer codigo) {
  this.codigo = codigo;
 }

 public String getNombre() {
  return nombre;
 }

 public void setNombre(String nombre) {
  this.nombre = nombre;
 }

 public Region getRegion() {
  return region;
 }

 public void setRegion(Region region) {
  this.region = region;
 }

 public List getPersonas() {
  return personas;
 }

 public void setPersonas(List personas) {
  this.personas = personas;
 }

 public Integer getCd_OfiRegion() {
  return Cd_OfiRegion;
 }

 public void setCd_OfiRegion(Integer cd_OfiRegion) {
  Cd_OfiRegion = cd_OfiRegion;
 }

}

package cl.sernapesca.siep.services;


import java.util.List;

import cl.sernapesca.siep.dto.OficinaDto;
import cl.sernapesca.siep.dto.PersonaDto;
import cl.sernapesca.siep.dto.RegionDto;
import cl.sernapesca.siep.entities.Log;
import cl.sernapesca.siep.entities.Oficina;
import cl.sernapesca.siep.entities.Persona;
import cl.sernapesca.siep.entities.Region;

public interface IMantenedorService {
 
 public List getPersonasByParam(PersonaDto persona);
 public List getAllPersonas();
 public Persona getPersonaByCodigo(Integer codigo);
 public boolean updatePersona(PersonaDto persona);
 public boolean removePersona(Persona persona);
 public Persona createPersona(PersonaDto personaDto);
 public List getPersonaByRutAndDv(Integer rut, String dv);
 
 public List getRegiones(RegionDto region);
 public Region getRegionByCodigo(Integer codigoRegion);
 public boolean updateRegion(Region region);
 
 public List getOficinas(OficinaDto oficina);
 public List getOficinasByCodigoRegion(Integer codigoRegion);
// public Oficina getOficinaByCodigo(Integer codigo);
 public boolean updateOficina(Integer codigo);
 
 public void createTraceLog(Log logObj);

}

package cl.sernapesca.siep.services.impl;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import cl.sernapesca.siep.dao.ILogDao;
import cl.sernapesca.siep.dao.IOficinaDao;
import cl.sernapesca.siep.dao.IPersonaDao;
import cl.sernapesca.siep.dao.IRegionDao;
import cl.sernapesca.siep.dto.OficinaDto;
import cl.sernapesca.siep.dto.PersonaDto;
import cl.sernapesca.siep.dto.RegionDto;
import cl.sernapesca.siep.entities.Log;
import cl.sernapesca.siep.entities.Oficina;
import cl.sernapesca.siep.entities.Persona;
import cl.sernapesca.siep.entities.Region;
import cl.sernapesca.siep.services.IMantenedorService;

@Service
public class MantenedorService implements IMantenedorService {

 @Autowired
 private IPersonaDao personaDao;
 @Autowired
 private IRegionDao regionDao;
 @Autowired
 private IOficinaDao oficinaDao;
 @Autowired
 private ILogDao logDao;

 public IPersonaDao getPersonaDao() {
  return personaDao;
 }

 public void setPersonaDao(IPersonaDao personaDao) {
  this.personaDao = personaDao;
 }

 public IRegionDao getRegionDao() {
  return regionDao;
 }

 public void setRegionDao(IRegionDao regionDao) {
  this.regionDao = regionDao;
 }

 public IOficinaDao getOficinaDao() {
  return oficinaDao;
 }

 public void setOficinaDao(IOficinaDao oficinaDao) {
  this.oficinaDao = oficinaDao;
 }

 @Override
 public List getPersonasByParam(PersonaDto persona) {

  return this.personaDao.findAllPersonaByParam(persona);
 }
 
 public ILogDao getLogDao() {
  return logDao;
 }

 public void setLogDao(ILogDao logDao) {
  this.logDao = logDao;
 }

 @Override
 public List getOficinasByCodigoRegion(Integer codigoRegion) {
  
  return this.oficinaDao.findOficinaByCodigoRegion(codigoRegion);
 }

 @Override
 public Persona getPersonaByCodigo(Integer codigo) {
  // TODO Auto-generated method stub
  return null;
 }
 
 @Override
 public List getPersonaByRutAndDv(Integer rut, String dv) {
  return this.personaDao.findPersonaByRutAndDv(rut, dv);
 }

 @Override
 public boolean updatePersona(PersonaDto personaDto) {
  Persona persona;
  Oficina personaOficinaUpdated;
  Region regionPersonaUpdated;
  
  persona = personaDao.findPersonaByCodigo(personaDto.getCodigo());
  
  
  if (persona != null) {
   persona.setNombre(personaDto.getNombre());
   persona.setRut(personaDto.getRut());
   persona.setDv(personaDto.getDv());
   persona.setUsuario(personaDto.getUsuario());
   if (persona.getOficina().getRegion().getCodigo() != personaDto.getRegionCodigo()){
    regionPersonaUpdated = regionDao.findRegionbyCodigo(personaDto.getRegionCodigo());
    
   }    
   
   if (persona.getOficina().getCodigo() != personaDto
     .getOficinaCodigo()) {
    personaOficinaUpdated = oficinaDao
      .findOficinaByCodigo(personaDto.getOficinaCodigo());
    if (personaOficinaUpdated != null)
     persona.setOficina(personaOficinaUpdated);
   }

  }
  
//  personaOficinaUpdated = (findOficinaByCodigo(personaDto.getOficinaCodigo()) != null) ? findOficinaByCodigo(personaDto.getOficinaCodigo()) : findOficinaByCodigo(personaDto.getOficinaCodigo()); 

  return this.personaDao.updatePersona(persona);
 }

 @Override
 public List getRegiones(RegionDto region) {
  // TODO Auto-generated method stub
  return this.regionDao.findRegionAll();
 }

 @Override
 public List getOficinas(OficinaDto oficina) {
  // TODO Auto-generated method stub
  return this.oficinaDao.findOficinaAll();
 }

 @Override
 public boolean updateRegion(Region region) {
  // TODO Auto-generated method stub
  return false;
 }

 @Override
 public boolean updateOficina(Integer codigo) {
  // TODO Auto-generated method stub
  return false;
 }

 @Override
 public Region getRegionByCodigo(Integer codigoRegion) {
  
  return this.regionDao.findRegionbyCodigo(codigoRegion);
 }

 @Override
 public boolean removePersona(Persona persona) {
  return this.personaDao.removePersona(persona);
 }

 @Override
 public Persona createPersona(PersonaDto personaDto) {
  Persona newPersona = new Persona();
  newPersona.setNombre(personaDto.getNombre());
  newPersona.setRut(personaDto.getRut());
  newPersona.setDv(personaDto.getDv());
  newPersona.setUsuario(personaDto.getUsuario());
  newPersona.setOficina(this.getOficinaDao().findOficinaByCodigo(personaDto.getOficinaCodigo()));
  return this.personaDao.createPersona(newPersona);
 }

 @Override
 public void createTraceLog(Log logObj) {
  
  this.logDao.createTraceLog(logObj);
  
 } 

 @Override
 public List getAllPersonas() {
  return this.personaDao.findPersonaAll();
 } 

}

El archivo de configuracion web-application-config.xml queda de la siguiente manera utilizando JPA, en el tambien declaramos la inyeccion de dependencias de Spring con la capa de datos el BEAN "entityManagerFactory" asegura persistencia y el BEAN "transactionManager":

Las transacciones de Spring Framework, valores agregados y tecnologías.

Ventajas del modelo de soporte de transacciones de Spring Framework describe por qué usted utilizaría la abstracción de transacciones de Spring Framework en lugar de transacciones administradas por el contenedor EJB (CMT) o la elección para conducir transacciones locales a través de una API propietaria como Hibernate.

La comprensión de la abstracción transacción Spring Framework describe las clases principales y describe cómo configurar y obtener DataSource casos de una variedad de fuentes. Sincronización de recursos con las transacciones describe cómo el código de la aplicación asegura que se crean recursos, reutilizados, y se limpian correctamente.

Gestión de transacciones declarativa describe el apoyo a la gestión de transacciones declarativa. Gestión de transacciones programática abarca el apoyo a programática (es decir, codificado explícitamente) la gestión de transacciones.
Transacción evento obligado describe cómo se puede utilizar eventos de aplicación dentro de una transacción.

package cl.sernapesca.siep.view.bean;

import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;

import javax.annotation.PostConstruct;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.ViewScoped;
import javax.faces.model.SelectItem;

import cl.sernapesca.siep.entities.Oficina;
import cl.sernapesca.siep.services.IMantenedorService;

@javax.faces.bean.ManagedBean
@ViewScoped
public class ConsultaOficinaBean implements Serializable {

 @ManagedProperty(value = "#{mantenedorService}")
 private IMantenedorService mantenedorService;
 private List listOficina;
 private List selectOficina;

 public IMantenedorService getMantenedorService() {
  return mantenedorService;
 }

 public void setMantenedorService(IMantenedorService mantenedorService) {
  this.mantenedorService = mantenedorService;
 }

 public List getListOficina() {
  return listOficina;
 }

 public void setListOficina(List listOficina) {
  this.listOficina = listOficina;
 }

 public List getSelectOficina() {
  return selectOficina;
 }

 public List getOficinasByCodigoRegion(Integer codigoRegion) {

  List results = this.mantenedorService
    .getOficinasByCodigoRegion(codigoRegion);
  if (this.getSelectOficina() != null)
   this.getSelectOficina().clear();
  this.setSelectOficina(new ArrayList());
  if (results.size() > 0) {
   for (Oficina o : results) {

    SelectItem si = new SelectItem();
    si.setLabel(o.getNombre());
    si.setValue(o.getCodigo());
    this.getSelectOficina().add(si);
   }
  } else {
   this.getSelectOficina().clear();
  }

  return this.getSelectOficina();
 }

 public void setSelectOficina(List selectOficina) {
  this.selectOficina = selectOficina;
 }

 @PostConstruct
 public void init() {

  this.setListOficina(mantenedorService.getOficinas(null));
 }

}

JSF es el estándar de JEE para la creación de interfaces de usuario basadas en componentes visuales y Spring Web es una extensión de Spring basada en el patrón ApplicationController para gestionar el flujo de navegación entre pantallas y mantener el estado de los objetos que participan en las mismas a modo de “conversación”, un ámbito superior al de petición e inferior al de sesión.



El ejemplo típico de conversación es el ámbito de los pasos de un carrito de la compra, un registro de usuarios o el proceso desde que seleccionamos un destino vacacional hasta que hacemos efectivo el pago del paquete en el que pueden verse implicados varios productos: hotel, vuelo, coche de alquiler,.. .

JSF también tiene su propia gestión de navegabilidad pudiendo realizarla de forma declarativa a través de XML o por convención de nomenclatura directamente en el resultado de las acciones. Si bien, antes de la versión 2 de JSF, la única manera de mantener un estado conversacional era usando el framework Jboss Seam, integrando la gestión de navegación con Spring Web Flow o ADF Tasks Flows.

Ahora, en la versión 2 de JSF, ya disponemos de un ámbito flash que, más que un ámbito, es un saco en el que ir metiendo objetos y mantenerlos de una vista a otra y, en la versión 2.2 de JSF, se introduce el concepto de Faces Flow, que introduce un ámbito de flujo de navegación (@FlowScoped)

JSF proporciona puntos de extensión que permiten, en este caso, a Spring Web Flow tomar el control sobre el manejo de las reglas de navegación y manejar el estado asociado con las interacciones de usuario, esto es, las conversaciones.

De este modo, con Spring Web podemos:

• implementar reglas de navegación dinánicas que puede modificarse en caliente sin necesidad de reiniciar el servidor,
• configurar forwards, refresh, redirect y navegación recursiva en el lenguaje de definición de flujos, rompiendo con el forward en el que se centra JSF y
• enapsular y modularizar la lógica de navegación a través del concepto de flujo.

Spring Web introduce 3 ámbitos de conversación que amplian los básicos de JSF (application, session y request):

• conversación: es el ámbito de duración de un diálogo con el usuario,
• flow: es el ámbito de duración de un flujo dentro de una conversación, y
• flash: es el ámbito de duración de una vista dentro de un flujo; vendría a ser el ámbito de vista (@ViewScope) nuevo en JSF2.

Se dice que estos ámbitos son manejados porque la limpieza de los objetos implicados es automáticamente gestionada por el contexto y ahí está la gracia, en poder mantener el estado de los objetos entre distintas vistas de navegación sin necesidad de usar la sesión y que sean manejados automáticamente por el contexto de Spring Web .

Ahora declarando el BEAN al usar JSF el faces-config.xml se simplifica usando la propiedad de SPRING MVC la inyección de dependencias.

   

   

 
  org.springframework.web.jsf.el.SpringBeanFacesELResolver
 

package cl.sernapesca.siep.view.bean;

import java.io.IOException;

import javax.faces.application.FacesMessage;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.validation.constraints.Size;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.AuthenticationException;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.savedrequest.HttpSessionRequestCache;
import org.springframework.security.web.savedrequest.SavedRequest;
import org.springframework.stereotype.Component;

@ManagedBean(name = "authenticationBean")
@RequestScoped
@Component
public class AuthenticationBean {

 @Autowired
 @Qualifier("authenticationManager")
 protected AuthenticationManager authenticationManager;

 @Size(min = 1, message = "Username cannot be empty")
 private String username;

 @Size(min = 1, message = "Password cannot be empty")
 private String password;

 public AuthenticationBean() {

 }

 public void setUsername(String username) {
  this.username = username;
 }

 public String getUsername() {
  return username;
 }

 public void setPassword(String password) {
  this.password = password;
 }

 public String getPassword() {
  return password;
 }

 /**
  * @return
  * @throws IOException
  * @throws ServletException
  */
 public String login() throws IOException, ServletException {

  try {

   Authentication request = new UsernamePasswordAuthenticationToken(this.username, this.password);

   Authentication result = authenticationManager.authenticate(request);

   SecurityContextHolder.getContext().setAuthentication(result);
   
   ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
   
   HttpServletResponse responseHTTP = (HttpServletResponse) FacesContext.getCurrentInstance().getExternalContext().getResponse();
   
   HttpServletRequest requestHTTP = (HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();

   SavedRequest defaultSavedRequest = new HttpSessionRequestCache().getRequest(requestHTTP, responseHTTP);
   
   context.redirect(defaultSavedRequest.getRedirectUrl());

   FacesContext.getCurrentInstance().responseComplete();

   return null;

  } catch (AuthenticationException e) {

   FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, e.getMessage(), e.getMessage()));
   return null;
  }



 }

 public String logout() throws IOException {
  this.username = "";
  this.password = "";
  ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
  context.redirect(context.getRequestContextPath() + "/j_spring_security_logout");
  FacesContext.getCurrentInstance().responseComplete();
  return null;
 }

}

Spring Web se integra con JSF, entre otros, a través de tres puntos de extensión:

• un listener propio del ciclo de vida de JSF, que permite manejar la ejecución de nuevos flujos cuando se invoca una petición por un cliente y que restaura el flujo de ejecución existente cuando se restaura la vista de JSF,
• un VariableResolver propio que hace trasparente que las referencias a los managedBean sean manejadas por el contexto de Spring, y
• un NavigationHandler propio que permite invocar al comportamiento adecuado y asignar la siguiente vista conforme a la definición de los flujos de navegación.

Con todo ello, seguimos teniendo todas las ventajas de trabajar con los componentes nativos de JSF porque la integración es transparente.
Para configurar Spring Web con JSF2 no es necesario declarar nada a nivel de JSF puesto que, al incluir las dependencias de la librería spring-faces, esta incorpora su propio faces-config.xml que se carga automáticamente con la configuración necesaria para JSF.
Lo que sí es necesario es configurar a nivel de aplicación web (web.xml) ambos servlets: el punto de entrada de JSF2 y el de Spring MVC, que sirve de enlace a Spring Web. Si toda la aplicación va a estar gestionada por Spring Web no haremos uso directo del servlet de JSF, solo nos servirá para levantar el contexto.

Ahora agregando seguridad al contexto de la pagina el flujo de navegacion seria como:

Lo más habitual es crear un application context separado del resto de los archivos de configuración de la aplicación. Vamos a crear este archivo que llamaremos security-app-context.xml dentro del WEB-INF y le añadimos este contenido:

 

 
 
  org.springframework.web.context.ContextLoaderListener
 

 
 
  javax.faces.PROJECT_STAGE
  Production
 
 
  contextConfigLocation
  
   /WEB-INF/web-application-config.xml
   /WEB-INF/web-application-security.xml 
  
 
 
  org.richfaces.skin
  classic
 
 
  org.richfaces.resourceOptimization.enabled
  true
 

 
 
  springSecurityFilterChain
  org.springframework.web.filter.DelegatingFilterProxy
 
 
  springSecurityFilterChain
  /*
  FORWARD
  REQUEST
 

 
 
  index.jsf
 
 

SPRING SECURITY:

Estamos usando el namespace de Spring Security para crear un configuración simple. En el bloque http, estamos diciendo que las expresiones para el control de acceso estan activadas y que usaremos un login basado en un formulario. Y en el intercept-url estamos diciendo que todo lo que cumpla el patron /** (el raíz y todos sus subdirectorios) es accesible a todo el mundo “permitAll”.

En el bloque del authentication-manager estamos definiendo una serie de usuarios en memoria con sus contraseñas y sus roles. En una aplicación real se pueden utilizar usuarios y roles de una base de datos, de un servidor LDAP o integrarse con sistemas de single sign-on (como por ejemplo OpenID).

Una vez configurado el archivo hay que añadirlo al context-param del web.xml

Archivo  web-application-security.xml

Bajar Proyecto Eclipse