Arquivo para novembro de 2013

Revertendo commits no SVN

Olá pessoal aqui vai um post rápido e sobre algo simples mas que muitas vezes nos causa dores de cabeça. Não muito raramente fazemos commits de códigos problemáticos e isso acaba nos tomando um certo tempo até voltar as coisas ao estágio anterior, mas é incrivelmente simples desfazer, ou reverter as mudanças de um commit com problemas. As ferramentas como o Subversion ou mesmo o plugin do Eclipse muitas vezes complicam um pouco mais as coisas e o bom mesmo é usar a velha linha de comandos para fazer o trabalho. Para isso precisamos apenas olhar os logs de commit e verificar a última versão commitada e a versão que deseja reverter. Com os números das revisões e a URL do repositório, basta montar o comando no DOS, Shell ou o que for de acordo com a estrutura abaixo:

svn merge -r [número_da_ultima_revisão]:[número_da_revisão_a_ser_revertida] [url_do repositório]

Após executar esse comando as alterações são revertidas na sua máquina e para aplicá-las ao repositório basta fazer um novo commit como se tivesse comitando algo novo e tudo se resolve. Lembrando que esse comando se aplica para o SVN.

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: , ,

Fazendo parser de objetos com o Dozer.

dozer

O framework Dozer é um parser de um POJO para outro POJO, o que significa dizer que ele copia automaticamente, de forma recursiva, dados de um objeto para outro.

O Dozer supporta mapear propriedades simples, tipos complexos, mapeamento bidirecional, mapeamento implicito-explicito, suporta também o mapeamento de coleções de atributos.

O Dozer suporta não somente o mapeamento entre nomes de atributos mas também faz conversões entre tipos. Para cenários mais complexos o Dozer permite realizar conversões customizadas através de arquivos XML.

O mapper é indicado sempre que você precisa copiar as informações de um POJO para outro. A maioria dos atributos podem ser mapeados automaticamente pelo Dozer através de reflexão, mas, como já foi comentado, qualquer mapeamento customizado pode ser feito através de arquivos XML. O mapeamento é bi-direcional somente o relacionamento entre as classes precisa ser definido. Se qualquer nome de alguma propriedade em ambos os objetos forem iguais você não precisará fazer nenhum mapeamento adicional para mapear essas propriedades.

A figura abaixo representa um exemplo em que é recomendável utilizar o Dozer em uma arquitetura. Note que ele é tipicamente usado nas entradas e saídas da aplicação. O Dozer garante que seus objetos de domínio interno não sejam vistos pelas camadas de apresentação ou por consumidores externos. Ele também pode ajudar a mapear seus objetos de domínio para chamadas externas de API’s e vice versa.

Em outras palavras, ao invés de você expor suas entidades JPA, por exemplo, o que indiretamente tornaria públicas informações de sua base de dados, você cria um POJO similar às suas entidades JPA, só que sem as anotações, e expõe esse POJO para os clientes de sua aplicação. Entre o POJO exposto e o a entidade JPA você poderia utilizar um framework como o Dozer e parsear dados de suas entidades JPA para o POJO exposto e vice e versa, encapsulando informações importantes de sua aplicação.
architecture
O Parser – “DozerParser”

No nosso exemplo temos um Parser genérico fazendo conversão de dois POJOS simples. Inicialmente criamos uma instância do Mapper, posteriormente temos dois métodos responsáveis por parsear um objeto e uma lista de objetos respectivamente.
Note que eles recebem objetos genéricos, o que significa que você pode usar da forma como está em um projeto seu que já vai funcionar. Logo abaixo temos um terceiro método que é quem efetivamente faz a invocação ao Dozer e este por sua vez realiza o parse.

package br.com.semeru.dozer.converter;

import java.util.ArrayList;
import java.util.List;

import org.dozer.DozerBeanMapper;
import org.dozer.Mapper;

public class DozerParser {

    private static final Mapper dozerMapper = new DozerBeanMapper();

    public static <O, D> D parseObjectInputToObjectOutput(O  originalObject, Class<D> destinationObject) {
        return parser(destinationObject, originalObject);
    }

    public static <O, D> List<D> parserListObjectInputToObjectOutput(List<O> originalObjects, Class<D> destinationObject) {
        List<D> destinationObjects = new ArrayList<D>();
        for (Object originalObject : originalObjects) {
            destinationObjects.add(parser(destinationObject, originalObject));
        }
        return destinationObjects;
    }

    private static <D> D parser(Class<D> destinationObject, Object originalObject) {
        return dozerMapper.map(originalObject, destinationObject);
    }
}

O objeto de origem – “InputObject”

Aqui temos um objeto de entrada, que é um POJO simples.


package br.com.semeru.dozer.objects;

import java.io.Serializable;

public class InputObject implements Serializable {

    private static final long serialVersionUID = 1L;

    private String name;
    private Integer age;

	// Getters, setters, equals e hashCode omitidos
}

O objeto de destino – “OutputObject”

Aqui temos o segundo POJO para onde os dados do objeto de entrada serão copiados. Note que a extrutura dos POJO’s devem ser iguais. Caso contrário você deveria personalizar o parser de acordo com a sua necessidade usando arquivos XML.

package br.com.semeru.dozer.objects;

import java.io.Serializable;

public class OutputObject implements Serializable {

    private static final long serialVersionUID = 1L;

    private String name;
    private Integer age;
    
	// Getters, setters, equals e hashCode omitidos
}

A classe de Mock – “MockInputObject”

Aqui temos uma classe de Mock que cria uma instância do POJO de entrada e popula-o com informações simulando um acesso à uma base de dados por exemplo.

package br.com.semeru.dozer.mocks;

import br.com.semeru.dozer.objects.InputObject;
import java.util.ArrayList;
import java.util.List;

public class MockInputObject {

    private InputObject inputObject = new InputObject();

    public InputObject mockInput() {
        inputObject.setName("Name Test");
        inputObject.setAge(21);
        return inputObject;
    }

    public List<InputObject> mockInputList() {
        List<InputObject> inputObjects = new ArrayList<InputObject>();
        for (int i = 0; i < 3; i++) {
            inputObjects.add(mockInput(i));
        }
        return inputObjects;
    }

    private InputObject mockInput(Integer number) {
        inputObject.setName("Name Test " + number);
        inputObject.setAge(20 + number);
        return inputObject;
    }
}

Os testes – “DozerParserTest”

Por fim temos os testes unitários que são responsáveis por verificar o comportamento do parser pasando as instancias mockadas pela classe acima pelo nosso parser e realizando asserções nos resultados.

package br.com.semeru.dozer.converter;

import br.com.semeru.dozer.mocks.MockInputObject;
import java.util.List;

import junit.framework.Assert;

import org.junit.Before;
import org.junit.Test;

import br.com.semeru.dozer.objects.OutputObject;

public class DozerParserTest {

    MockInputObject inputObject;

    @Before
    public void setUp() {
        inputObject = new MockInputObject();
    }

    @Test
    public void parseObjectInputToreObjectOutputTest() {
        OutputObject output = DozerParser.parseObjectInputToObjectOutput(inputObject.mockInput(), OutputObject.class);
        Assert.assertEquals("Name Test", output.getName());
        Assert.assertTrue(output.getAge() == 21);
    }

    @Test
    public void parserListObjectInputToObjectOutputTest() {
        List<OutputObject> output = DozerParser.parserListObjectInputToObjectOutput(inputObject.mockInputList(), OutputObject.class);
        Assert.assertEquals("Name Test 2", output.get(0).getName());
        Assert.assertTrue(output.get(0).getAge() == 22);
    }
}

Enfim o Dozer é uma ótima opção de parser de um POJO para outro sendo também bastante simples de se usar. Como alternativa ao Dozer temos o Orika que faz as mesmas tarefas que o Dozer. No meu Github você pode ver um exemplo básico de utilização do Dozer e do Orika. Bom proveito e faça bons estudos.

Tags: , ,