Arquivo por categoria Apache Maven

Criando um novo projeto a partir de um Archetype Maven

Em uma postagem anterior você viu como criar um Archetype Maven a partir de um projeto existente agora chegou o momento de criarmos um projeto novo a partir do nosso archetype. Primeiro você precisa clonar esse projeto no seu computador. Para isso abra o terminal no diretório em que deseja armazenar o código e execute o comando abaixo.

git clone https://github.com/leandrocgsi/erudio-rest-api-archetype.git

Abra a pasta gerada ela deverá se parecer com a imagem abaixo.

OpenFolder

Abra o terminal nessa pasta e execute o seguinte comando.

mvn clean install

Ele deve se parecer com a imagem abaixo

CleanInstall

Agora vá até o diretorio em que deseja criar o seu projeto e execute o seguinte comando (formatado para facilitar a leitura execute tudo na mesma linha).

mvn archetype:generate -DarchetypeGroupId=br.com.semeru
    -DarchetypeArtifactId=jsf-hibernate-spring-security-archetype
    -DarchetypeVersion=0.1.0
    -DgroupId=br.com.your.domain
    -DartifactId=your-project-name
    -Dversion=1.0-SNAPSHOT
    -Dpackage=br.com.your.domain

Onde você deve ajustar os parâmetros DgroupId para seu group ID, DartifactId para o nome do seu projeto, Dversion para o numero de versão desejado, Dpackage para sua base de pacotes.

Ele deve se parecer com a imagem abaixo.

GenerateProject

O Maven irá lhe perguntar se você deseja alterar a versão do seu projeto e a estrutura de pacotes como está destacado na imagem abaixo. Se você não quiser alterar nada apenas digite Enter Enter. Se tudo tiver corrido bem você deverá ver uma imagem similar à que se segue e isso significa que o seu projeto foi criado com sucesso 😉

Building1

Agora só precisamos importar nosso projeto na nossa IDE favorita (STS – Spring Suource Tool Suite, baseada no Eclipse, no meu caso). Acesse o menu File >> Import >> Maven >> Existing Maven Projects >> Next.

Importing1

Como na imagem abaixo digite ou navegue até o diretório onde se encontra o seu código e clique em Browse >> Finish.

Importing2

Agora que tudo está pronto basta codar a nossa aplicação. Caso não saiba como executar o projeto clique aqui e siga o passo a passo.

Tags: , ,

Criando um Archetype Maven a partir de um projeto existente


Maven archetypes são templates de projetos que possibilitam iniciar o desenvolvimento de novos projetos rapidamente baseando se em uma base de arquivos, xml’s e classes já existentes. Um bom exemplo disso são os archetypes da fundação JBoss que possibilitam a criação de uma enorme variedade de arquiteturas para esse ambiente. Você pode por exemplo criar uma aplicação JEE em questão de minutos apenas executando um simples comando. No meu caso eu vou criar um template de uma API RESTful para que eu possa criar novas aplicações com esse comportamento com maior rapidez no futuro. A estrutura do nosso archetype será construido a partir do projeto Erudio API OAUTH2 que é uma aplicação RESTful com Spring Boot.


Existem duas formas de se criar um archetype Maven:


1. Construir o template do zero adicionando os arquivos necessários
2. Executar o Maven archetype plugin em um projeto já existente e configurá-lo. No nosso caso escolheremos a segunda opção.


Primeiro precisamos navegar até o diretório raiz do nosso projeto fonte e executamos o comando abaixo:


mvn archetype:create-from-project


Depois de toda a mágica você deverá ver uma tela de sucesso similar a imagem abaixo com a expressão “BUILD SUCCESS”. Note que a mensagem de sucesso aparece duas vezes, a primeira delas é referente a construção da estrutura do archetype e a segunda se refere a criação do mesmo.


[INFO] Scanning for projects...
Downloading: https://repo.spring.io/plugins-release/org/codehaus/mojo/maven-metadata.xml
Downloading: https://repo.spring.io/plugins-release/org/apache/maven/plugins/maven-metadata.xml
Downloaded: https://repo.spring.io/plugins-release/org/apache/maven/plugins/maven-metadata.xml (18 KB at 5.3 KB/sec)
Downloaded: https://repo.spring.io/plugins-release/org/codehaus/mojo/maven-metadata.xml (27 KB at 7.9 KB/sec)
Downloading: https://repo.spring.io/plugins-release/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml
Downloaded: https://repo.spring.io/plugins-release/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml (784 B at 0.9 KB/sec)
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building erudio-api-oauth2 0.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.4:create-from-project (default-cli) > generate-sources @ erudio-api-oauth2 >>>
[INFO]
[INFO] --- gmaven-plugin:1.5:generateStubs (default) @ erudio-api-oauth2 ---
[INFO] Generated 13 Java stubs
[INFO]
[INFO] <<< maven-archetype-plugin:2.4:create-from-project (default-cli) < generate-sources @ erudio-api-oauth2 <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.4:create-from-project (default-cli) @ erudio-api-oauth2 ---
[INFO] Setting default groupId: br.com.erudio
[INFO] Setting default artifactId: erudio-api-oauth2
[INFO] Setting default version: 0.1.0
[INFO] Setting default package: br.com.erudio
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building erudio-api-oauth2-archetype 0.1.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ erudio-api-oauth2-archetype ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 116 resources
[INFO]
[INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @ erudio-api-oauth2-archetype ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-archetype-plugin:2.4:jar (default-jar) @ erudio-api-oauth2-archetype ---
[INFO] Building archetype jar: D:\SandBox\MyCode\erudio-api-oauth2\target\generated-sources\archetype\target\erudio-api-oauth2-archetype-0.1.0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.121 s
[INFO] Finished at: 2016-05-11T13:53:05-03:00
[INFO] Final Memory: 12M/121M
[INFO] ------------------------------------------------------------------------
[INFO] Archetype project created in D:\SandBox\MyCode\erudio-api-oauth2\target\generated-sources\archetype
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27.668 s
[INFO] Finished at: 2016-05-11T13:53:06-03:00
[INFO] Final Memory: 30M/212M
[INFO] ------------------------------------------------------------------------
$


Acesse o diretório gerado target/generated-sources/archetype e copie o conteudo do pom.xml e da pasta src para um novo diretório caso necessário faça suas alterações.
A estrutura raiz do projeto deve ser similar a imagem abaixo:


Estrutura de Pastas


A pasta target pode ser deletada com o comando mvn clean. O pom.xml do archetype possui apenas o necessário para construir um novo projeto. Uma boa seria alterarmos a versão para 1.0-SNAPSHOT uma vez que ainda não é uma versão final.
Em src/ por sua vez estão os fontes do nosso archetype.
Continuem ligados e em uma próxima postagem explicarei como criar um novo projeto a partir do recém criado archetype.

Tags: , ,

Usando código Groovy (o Java com esteróides) juntamente com código Java em um projeto com Spring Boot

Mais um post em que explico como integrar código Groovy junto ao seu código Java em um projeto com Spring Boot usando o gerenciador de dependencias Maven. No outro post usamos o ‘Groovy Eclipse Compiler Plugin‘ mas nunca consegui fazer ele funcionar corretamente com o Spring Boot então o substituimos pelo ‘GMaven Plugin‘. Além disso o ‘Groovy Eclipse Compiler Plugin‘ tem problemas de backward compatibility com o Java 8 diferentemente do ‘GMaven Plugin‘.
Então mãos a obra, adicione as configurações abaixo ao seu pom.xml e tenha todo poder do Groovy junto ao seu código Java.

	
	<!-- Adicione o Groovy às dependências do seu projeto -->
	<dependencies>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <scope>compile</scope>
        </dependency>
	</dependencies>		
     
        .
        .
        .       
     
	<!-- Será necessário fazer algumas mudanças no seu processo de build --> 		
	<build>
		<resources>
			<resource>
				<directory>${basedir}/src/main/resources</directory>
			</resource>
		</resources>
		
		<!-- Adicione o GMaven Plugin -->
		<plugins>
			<plugin>
				<groupId>org.codehaus.gmaven</groupId>
				<artifactId>gmaven-plugin</artifactId>
				<version>1.5</version>
				<configuration>
					<providerSelection>2.0</providerSelection>
				</configuration>
				
				<!-- Adicione as dependencias 'gmaven-runtime-2.0' e 'groovy-all' ao plugin -->
				<dependencies>
					<dependency>
						<groupId>org.codehaus.gmaven.runtime</groupId>
						<artifactId>gmaven-runtime-2.0</artifactId>
						<version>1.5</version>
					</dependency>
					<dependency>
						<groupId>org.codehaus.groovy</groupId>
						<artifactId>groovy-all</artifactId>
						<version>2.1.8</version>
					</dependency>
				</dependencies>
				
				<!-- Defina suas metas de execução -->
				<executions>
					<execution>
						<goals>
							<goal>generateStubs</goal>
							<goal>compile</goal>
							<goal>generateTestStubs</goal>
							<goal>testCompile</goal>
						</goals>
					</execution>
				</executions>
			</plugin>

			<!-- Adicione o plugin do 'spring-boot-maven-plugin' -->			
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
			
		</plugins>
	</build>

Caso você tenha dúvidas poderá se basear em um projeto completo no Github o Erudio API OAUTH2 utilizando essas tecnologias juntas. Lets Groovy guys, bons estudos.

Tags: , , , ,

Usando código Groovy (o Java com esteróides) juntamente com código Java

Existem várias maneiras de se usar Groovy junto ao seu código Java. As mais usadas são com Gradle e Maven. No maven podemos usar o GMaven ou o Groovy Eclipse compiler plugin. Pessoalmente eu uso este ultimo e segue abaixo as configurações básicas pra que você tenha todo poder do Groovy a seu dispor.

	
	<!-- Adicione o Groovy às dependências do seu projeto -->
	<dependencies>
            <dependency>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-all</artifactId>
                <version>2.1.6</version>
            </dependency>
	</dependencies>
		
			.
			.
			.		
		
	<!-- Será necessário fazer algumas mudanças no seu processo de build -->	
	<build>
	
			.
			.
			.	
			
        <plugins>        

			.
			.
			.			
        
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
				
				<!-- Adicione o Groovy Eclipse compiler as suas configurações -->
                <configuration>
                    <compilerId>groovy-eclipse-compiler</compilerId>
                    <source>1.6</source>
                    <target>1.6</target>
                    <encoding>${project.build.sourceEncoding}</encoding>
                </configuration>
				
				<!-- Adicione as dependencias 'groovy-eclipse-compiler' e 'groovy-eclipse-batch' -->
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-compiler</artifactId>
                        <version>2.8.0-01</version>
                    </dependency>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-batch</artifactId>
                        <version>2.1.5-03</version>
                    </dependency>
                </dependencies>
            </plugin>
			
			<!-- Adicione o plugin 'groovy-eclipse-compiler' -->
            <plugin>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-eclipse-compiler</artifactId>
                <version>2.8.0-01</version>
                <extensions>true</extensions>
            </plugin>            
        </plugins>         
    </build>

Não lhe garanto que em alguns momentos você passará por frustrações, principalmente por causa do Eclipse. Mas lhe garanto que vale a pena.

Tags: , ,

Trabalhando com Maven e os plugins ‘jboss-as-maven-plugin’ e ‘maven-antrun-plugin’

E agora vai um post rápido e rasteiro ensinando como aproveitar uma das funcionalidades mais bacanas providas pelo Maven quando trabalhamos com o JBoss AS 7 ou JBoss EAP é o deploy automático dos artefatos diretamente no contêiner. Isso acaba por facilitar bastante o processo de test in code. Para isso precisamos apenas adicionar o plugin ‘jboss-as-maven-plugin’ conforme descrito no trecho abaixo.

<build>
   <finalName>${project.artifactId}</finalName>
  <!-- Na linha acima passamos uma variável com o nome final do artefato -->
  
  <!-- Dentro da tag build definimos quais plugins usaremos -->
   <plugins>
    
    <!-- Aqui definimos os plugins que usaremos dentre eles o de deploy-->
  
    <plugin>
      <groupId>org.jboss.as.plugins</groupId>
      <artifactId>jboss-as-maven-plugin</artifactId>
        <configuration>
           <filename>${project.artifactId}.ear</filename>
           <skip>false</skip>
        </configuration>
      <executions>
        <execution>
          <phase>install</phase>
          <goals>
            <goal>deploy</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
   </plugins>
</build>

A parte ruim da brincadeira é que ele não funciona direito em versões anteriores do JBoss, mas pra isso temos uma solução um pouco menos elegante mas que reolve o problema.
Para isso usaremos um outro plugin o ‘maven-antrun-plugin’ ele é capaz de executar uma série de tarefas como copiar e deletar arquivos. Para facilitar as coisas pode ser interessante criar uma variável de ambiente que aponte para o diretório de instalação do seu JBoss o que facilita o desenvolvimento em equipe e dispensa a necessidade de colocar o path completo.

<build>
  <plugins>
    
    <!-- Aqui definimos os plugins que usaremos dentre eles o de deploy-->
     
    <plugin>
      <artifactId>maven-antrun-plugin</artifactId>
      <executions>
        <execution>
          <id>deploy-DU</id>
          <phase>install</phase>
          <goals>
            <goal>run</goal>
          </goals>
          <configuration>
            <tasks>
              <!-- Aqui copiamos o artefato gerado no diretório target para o diretório de deploy do JBoss -->
              <copy overwrite="true" file="target/myproject-${project.version}.ear" todir="${env.JBOSS_HOME}/server/default/deploy" />
            </tasks>
          </configuration>
        </execution>
        <execution>
          <id>undeploy-DU</id>
          <phase>clean</phase>
          <goals>
            <goal>run</goal>
          </goals>
          <configuration>
            <tasks>
              <!-- Aqui dizemos ao Maven para deletar a versão anterior do nosso artefato no diretório de deploy do JBoss-->
              <delete file="${env.JBOSS_HOME}/server/default/deploy/myproject-${project.version}.ear" />
            </tasks>
          </configuration>
        </execution>
      </executions>
    </plugin>  
  </plugins>     
</build>

Sem muito segredo simples e rápido bons estudos a todos.

Tags: , ,

Iniciando Se No JSF – 03 – A Arquitetura Da Aplicação



Bom a imagem abaixo representa a estrutura de pacotes em que se divide nossa aplicação. De cima para baixo temos as pastas META-INF e WEB-INF a primeira delas não tem muita relevância nesse caso já a segunda é reponsável por armazenar os arquivos de configuração de nossa aplicação como faces.config.xml que armazena as configurações do JSF, o web.xml que mapeia listeners, servlets e demais configurações da aplicação e por fim temos o spring-security.xml que armazena as configurações de segurança de nossa aplicação. Um pouco abaixo temos as pastas public, restrict e resources. A pasta public no nosso projeto conterá as páginas que poderão ser acessadas sem a necessidade de autenticação por parte do usuário a restrict por sua vez armazena as páginas que só serão acessadas por usuários autenticados e autorizados. A pasta resources contém outras duas pastas public e restrict onde são armazenados arquivos de css, javascript e templates Facelets correspondentes as páginas publicas e restritas.
Logo abaixo temos nossa estrutura de pacotes. Inicialmente temos o pacote br.com.semeru.controller que armazena as classes da camada de controle de nossa aplicação. Logo abaixo temos o pacote br.com.semeru.conversores que armazena as classes responsáveis por converter dados, como por exemplo criptografar uma senha. Logo abaixo temos o pacote br.com.semeru.exceptions que armazena as classes responsáveis por tratar as exceções ocorridas na aplicação. Logo abaixo temos o pacote br.com.semeru.i18n que é responsável por prover internacionalização da aplicação, entretanto isso ainda não foi aplicado no projeto atual. Mais abaixo temos o pacote br.com.semeru.dao que armazena a uma interface do DAO e uma classe de DAO Genérico que é responsável por acessar os a base de dados. Um pouco mais abaixo temos o pacote br.com.semeru.entities que armazena as entidades que representam as tabelas do banco de dados da nossa aplicação. Vale destacar que nossa arquitetura segue o padrão MVC onde as páginas representam a camada de visão (V) os DAO’s e as Entidades representam o modelo (M) e o controle é representado pelos nossos ManagedBeans. Logo abaixo temos o pacote br.com.semeru.suport que armazena os BackingBeans de nossa aplicação essas classes são reponsáveis por oferecer suporte à página não processando nada e raramente contendo regras de negócio. Por fim temos o pacote br.com.semeru.validators que armazena as classes responsáveis por realizar validações de dados no projeto.
Temos ainda no pacote default o arquivo hibernate.cfg.xml, a fim de manter o projeto levemente mais simples vamos mantê-lo no pacote default. Pouco depois temos o pacote ScriptsSQL que contem o backup de alguns dados do nosso banco e depois o arquivo pom.xml que é o responsável por armazenar as configurações do Maven. Não irei me aprofundar muito em explicações do Maven para entender melhor sobre o maven acesse este link, este e este.

ArquiteturaSemeru

05 – Curso De JSF Do Zero À Nuvem – Definindo A Estrutura De Pacotes

Nesse vídeo iremos montar toda a estrutura de pacotes onde é explicado com mais detalhe todo o projeto.



Aqui temos a classe HibernateUtil que é responsável por criar a SessionFactory que nos permitirá acessar a base de dados. Inicialmente declaramos uma instância de SessionFactory e depois uma constante com a sessão do Hibernate. Logo abaixo temos um bloco estático que é responsável por tentar criar uma SessionFactory. Inicialmente declaramos uma instância de Configuration. Posteriormente tentamos registrar uma SessionFactory para isso passamos como parâmetro no método applySettings as informações do nosso hibernate.cfg.xml se mudarmos esse arquivo para um pacote diferente do default deveremos passar sua localização como parâmetro configuration.getProperties, caso contrário o Hibernate não saberá se localizar. Caso ocorra alguma falha nesse processo uma exception será lançada. Por fim temos o o método getSessionFactory que é o responsável por permitir a obtenção da SessionFactory pelo nosso PhaseListener, que será abordado mais abaixo.

package br.com.semeru.util;

import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.hibernate.service.ServiceRegistry;
import org.hibernate.service.ServiceRegistryBuilder;

public class HibernateUtil {
    
    private static final SessionFactory sessionFactory;
    public static final String HIBERNATE_SESSION = "hibernate_session";
    
    static{
        
        try {     
            Configuration configuration = new Configuration().configure();
            
            ServiceRegistry serviceRegistry = new ServiceRegistryBuilder().
                applySettings(configuration.getProperties()).buildServiceRegistry();            
            sessionFactory = configuration.buildSessionFactory(serviceRegistry);                        
        } catch (Exception ex) {
            throw new ExceptionInInitializerError(ex);
        }                
    }

    public static SessionFactory getSessionFactory() {
        return sessionFactory;
    }
    
}



06 – Curso De JSF Do Zero À Nuvem – Criando A Classe HibernateUtil

Aqui temos o processo de criação da classe HibernateUtil que detalha um pouco mais essas informações.



07 – Curso De JSF Do Zero À Nuvem – Removendo Dependência Duplicada E slf4j



Nesse vídeo removemos uma dependência duplicada e o slf4j que estavam impedindo a execução de nosso projeto.





Aqui temos as nossa InterfaceDAO que define os métodos que o nosso DAO genérico deverá implementar. São eles save, update, remove, merge responsáveis por salvar, atualizar, remover e tanto salvar quanto atualizar respectivamente. Temos também os métodos de leitura como por exemplo o getEntity que obtém um objeto no banco, o getEntityByDetachedCriteria que obtém um objeto no banco através de uma DetachedCriteria, o getEntities que obtém uma lista de objetos no banco e getListByDetachedCriteria que obtém uma lista de objetos no banco através de uma DetachedCriteria.

package br.com.semeru.model.dao;

import java.io.Serializable;
import java.util.List;
import org.hibernate.criterion.DetachedCriteria;

public interface InterfaceDAO<T> {
    
    void save (T entity);
    void update (T entity);
    void remove (T entity);
    void merge (T entity);
    T getEntity(Serializable id);
    T getEntityByDetachedCriteria(DetachedCriteria criteria);
    List<T> getEntities();
    List<T> getListByDetachedCriteria(DetachedCriteria criteria);    
    
}


Aqui temos a nossa classe HibernateDAO que é de tipagem genérica, o que siginfica que o nosso DAO possibilitará a persistencia de todas as entidades da nossa aplicação. No nosso construtor obrigamos a sempre passar o tipo da entidade que queremos persistir e a sessão do hibernate para que o DAO faça o serviço. Além disso toda a implementação é bastante simples, sendo necessário apenas usar a session do hibernate e executar seus métodos passando a entidade envolvida como parâmetro.


package br.com.semeru.model.dao;

import java.io.Serializable;
import java.util.List;
import org.hibernate.Criteria;
import org.hibernate.Session;
import org.hibernate.criterion.DetachedCriteria;

public class HibernateDAO<T> implements InterfaceDAO<T>, Serializable {

    private static final long serialVersionUID = 1L;
    
    private Class<T> classe;
    private Session session;

    public HibernateDAO(Class<T> classe, Session session) {
        super();
        this.classe = classe;
        this.session = session;
    }
    
    
    @Override
    public void save(T entity) {
        session.save(entity);
    }

    @Override
    public void update(T entity) {
        session.update(entity);
    }

    @Override
    public void remove(T entity) {
        session.delete(entity);
    }

    @Override
    public void merge(T entity) {
        session.merge(entity);
    }

    @Override
    public T getEntity(Serializable id) {
        T entity = (T)session.get(classe, id);
        return entity;
    }

    @Override
    public T getEntityByDetachedCriteria(DetachedCriteria criteria) {
        T entity = (T)criteria.getExecutableCriteria(session).uniqueResult();
        return entity;
    }

    @Override
    public List<T> getListByDetachedCriteria(DetachedCriteria criteria) {
        return criteria.getExecutableCriteria(session).list();
    }
    
    @Override
    public List<T> getEntities() {
        List<T> enties = (List<T>) session.createCriteria(classe).list();
        return enties;
    }    
    
}


08 – Curso De JSF Do Zero À Nuvem – Criação Do DAO Genérico

Nesse vídeo nós criamos a interface e o DAO genérico, neles você terá informações com maiores detalhes.


Aqui temos a classe FacesContextUtil que é responsável por colocar na sessão do usuário (FacesContext) do JSF, a sessão do Hibernate. Como se pode perceber ela possui um atributo estático que é a chave da sessão do Hibernate e dois métodos set e get. O primeiro deles captura o RequestMap do FacesContext e atribui a ele a sessão do Hibernate. O segundo método obtém de volta a sessão do Hibernate para que o PhaseListenerSemeru possa realizar o commit na transação como será explicado mais abaixo.


package br.com.semeru.util;

import javax.faces.context.FacesContext;
import org.hibernate.Session;

public class FacesContextUtil {

    private static final String HIBERNATE_SESSION = "hibernate_session";

    public static void setRequestSession(Session session){
        FacesContext.getCurrentInstance().getExternalContext().getRequestMap().put(HIBERNATE_SESSION, session);
    }
    
    public static Session getRequestSession() {
        return (Session)FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(HIBERNATE_SESSION);
    }
    
}

Antes de partir para a próxima etapa recomendo que você leia este post que explica como funciona o ciclo de vida do JSF. Agora aproveite para assistir também a parte teórica do video abaixo em que isso é abordado com mais detalhes.

09 – Curso De JSF Do Zero À Nuvem – O Ciclo De Vida De Uma Request No JSF E O FacesContextUtil



Atuando junto à classe FacesContextUtil temos a classe PhaseListenerSemeru é a responsável por auxiliar o sistema de login e por implementar o padrão Open Session in View do Hibernate. Open Session in View consiste em iniciar a transação quando é feita uma requisição e encerrá-la quando a página é renderizada. O PhaseListenerSemeru implementa a interface PhaseListener do JSF e possui três métodos beforePhase, afterPhase e getPhaseId. O método beforePhase verifica se a fase está antes da Restore View (Restaurar a Visão), se estiver ele abre a sessão do Hibernate e coloca-a na requisição do usuário passando-a para o FacesContext. O segundo método, verifica se a fase Render Response (Renderizar a Resposta) foi executada, se sim, ele tenta commitar a transação. Se ocorrer algum erro ele imprime uma mensagem no log, nesse momento, caso a sessão ainda esteja ativa ele executa um rollback e finalmente fecha a sessão. Caso não ocorram erros ele encerra a transação e fecha a sessão. Já o terceiro método, o getPhaseId é responsável por especificar em que fase o PhaseListener deve ser acionado, no nosso exemplo ele é acionado em todas as fases. Dessa forma, a classe PhaseListenerSemeru implementa o Open Session in View de forma transparente para o desenvolvedor. Essa abordagem torna desnecessário, ao desenvolvedor, se preocupar com abrir e fechar a sessão. Toda a responsabilidade pelo controle de sessão passa a ser feito pelo PhaseListenerSemeru através da verificação das fases da requisição no FacesContext, do JSF.

package br.com.semeru.util;

import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import org.hibernate.Session;

public class PhaseListenerSemeru implements PhaseListener {

    //Antes da Fase
    @Override
    public void beforePhase(PhaseEvent fase) {
        System.out.println("Antes da fase: "+ fase.getPhaseId());
        if (fase.getPhaseId().equals(PhaseId.RESTORE_VIEW)) {            
            Session session = HibernateUtil.getSessionFactory().openSession();
            session.beginTransaction();
            FacesContextUtil.setRequestSession(session);            
        }
    }
    
    //Depois da Fase
    @Override
    public void afterPhase(PhaseEvent fase) {
        System.out.println("Depois da fase: "+ fase.getPhaseId());
        if (fase.getPhaseId().equals(PhaseId.RENDER_RESPONSE)) {
            Session session = FacesContextUtil.getRequestSession();
            try {
                session.getTransaction().commit();
            } catch (Exception e) {
                if (session.getTransaction().isActive()) {
                    session.getTransaction().rollback();
                }
            } finally{
                session.close();
            }
        }
    }

    @Override
    public PhaseId getPhaseId() {
        return PhaseId.ANY_PHASE;
    }
    
}

Para reforçar os conceitos sobre o PhaseListener assista mais essa vídeo aula.

10 – Curso De JSF Do Zero À Nuvem – O PhaseListener

Agora que temos uma visão geral mais clara botaremos para quebrar nos próximos posts. Lembrando que os comentários são importantes para que eu possa ir melhorando gradativamente os posts. Quero destacar também que os fontes desse curso podem ser baixados do GitHub. Serão feitos posts correspondentes às demais vídeo aulas e assim que possível irei realizando posts para complementar o que foi falado nos vídeos. É isso aí bons estudos.

Tags: , ,