Converter JSF com Spring

 

Olá Pessoal,

O post de hoje será bem rápido. Se você está  precisando criar um Converter e fazer com que este seja gerenciado pelo Spring, o que fazer? Ao olhar a documentação do Spring não há nenhuma anotação direta para o Converter. Lets go! Vamos ver na prática como fazer isso…

 

Converter

Um resumo rápido: Sabemos que quando precisamos carregar um selectOneMenu, por exemplo, um valor customizado, é preciso ter um converter, como por exemplo se preciso carregar cidade, estado, status,  etc é necessário ter um converter, e para implementarmos um converter temos que criar uma classe que implementa a interface Converter do JSF. Nada de especial até aqui, certo?

@FacesConverter( value= “com.camilolopes.readerweb.TypeConverter”,forClass=Type.class)

public class TypeConverter implements Converter {

       @Override

public Object getAsObject(FacesContext context, UIComponent component, String value) {

 

return null;

       } 

       @Override

public String getAsString(FacesContext arg0, UIComponent arg1, Object value) {

             

return null;

       } 

}

Mas você está usando o Spring e quer que seu Converter seja gerenciado por ele, e ainda assim poder chamar as classes de serviços, como fazer? Veja o código alterado com Spring e chamando um método na classe de serviço: 

@Component(“typeConverter”)

public class TypeConverter implements Converter {

       @Autowired

       private TypeServiceImpl typeServiceImpl;

       @Override

public Object getAsObject(FacesContext context, UIComponent component, String value) { 

              Type type = typeServiceImpl.searchById(Long.valueOf(value));

              return type;

       } 

       @Override

       public String getAsString(FacesContext arg0, UIComponent arg1, Object value) {

                     if(value!=null){

                           return ((Type)value).getId().toString();

                     }

              return null;

       } 

       public TypeServiceImpl getTypeServiceImpl() {

              return typeServiceImpl;

       } 

       public void setTypeServiceImpl(TypeServiceImpl typeServiceImpl) {

              this.typeServiceImpl = typeServiceImpl;

       } 

}

Basta anotar com @Component e definir um id para o converter. Na página XHTML chamaremos o id usando EL, veja:

<p:selectOneMenu value=“#{userController.selectedType}” converter=“#{typeConverter}”>

<f:selectItems  itemLabel=“#{type.description}” itemValue=“#{type}” var=“type”  value=“#{typeController.listTypes}” />

</p:selectOneMenu>

Pronto, assim temos o converter via Spring. Claro que você precisar ter no seu face-config.xml na tag <application />

<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>

 Dizendo para o JSF que o Spring vai cuidar da instanciação dos objetos etc. Veja nesse post.

Por hoje é isso. See ya!!

Internacionalização sua aplicação com JSF

Olá Pessoal,

No post de hoje veremos como internacionalizar nossa aplicação JSF.  Eu acho o suporte de internacionalização do JSF muito simples e fácil. É comum você trabalhar em um projeto e o cliente falar que deseja dar suporte pelo menos a 2 idiomas: um default e +1. Veremos como preparar nossa aplicação para isso. Lets go…

Starting…

O JSF procura os arquivos de tradução em um local, que é dentro de resources / src/main/resources, então é lá que vamos colocar os .properties para cada idioma que a aplicação vai suportar. No exemplo aqui será português e inglês, portanto crie dois arquivos .properties chamado: language_en_US e language_pt_BR.  O nome language pode ser qualquer outro. O que teremos nele? Como qualquer arquivo de properties um key=value, é nele que vamos colocar a tradução da aplicação dos labels, message etc. Dentro de src/main/resources crie o seguinte package: com/camilolopes/readerweb/idiom, é onde ficarão nossos arquivos .properties. Poderia deixar na raiz, mas quis colocar em package para ficar organizado.

 

jsfinterproperties

Feito isso, abra o seu face-config.xml e faça isso dentro de application:

<locale-config>

   <default-locale>pt_BR</default-locale>

   <supported-locale>pt_BR</supported-locale>

   <supported-locale>en_US</supported-locale>

  </locale-config>

  <!– Local where is .properties –>

  <resource-bundle>

       <base-name>com.camilolopes.readerweb.idiom.language</base-name>

       <!–  variable will be used in system of context –>

       <var>language</var>

  </resource-bundle>

 

Observe que criamos uma variável. É ela que vamos usar no XHTML passando o key do .properties para que possa ser traduzido com base no idioma definido no browser.

Colocando tradução no .properties

Eu particularmente gosto muito do plugin Resource Bundle http://sourceforge.net/projects/eclipse-rbe/ , pois ele me permite de uma única vez atualizar os dois arquivos  .properties, já inserindo a tradução, veja:

 

jsfpropertiesbundle

Se você usa o Eclipse é só instalar o plugin, mas ele não está no Eclipse Market, é old school, ou seja, você vai na pasta plugin do seu eclipse e cola todo o conteúdo de plugin que está no resource bundle que você acabou de baixar.

Usando na Prática

<h:outputLabel value=“#{language[‘label.type.description’]}” for=“name” />

<h:commandButton value=“#{language[‘command.save’]}” />

 

Resultado:

jsfinterlabelenglish

 

jsfinterlabelpt

Simples, não? Conheça API I4JSF

Espero que tenham gostado. See ya!!!

Abraços.

IMasterPro: Curso de TDD em Java

Olá Pessoal, 
 
O post de hoje na verdade é para apresentar para vocês mais um curso que estou lançando no IMasterPro, o objetivo é para aquele que querem aprender TDD, já até tentou, mas não conseguiu ir muito adiante e não pegou o jeito da coisa. E como eu já passei por isso e tive bastante dificuldade na época em encontrar material mais focado e bem direcionado em nosso idioma, resolvi  montar o curso online para ajudar quem está chegando agora. A seguir  falo um pouco sobre o curso.
lets go..
 
Sobre o Curso 
Se você espera um curso teorico e cheio de bla bla, esquece. Nem eu gosto de curso assim. Fiz o curso bem focado na prática, ou seja, mão na massa. Com problemas, exercicios práticos para que você possa ir resolvendo a medida que vamos evoluindo no aprendizado. Não tem jeitinho brasileiro, receita de bolo para aprender. A única forma é praticar e não ter preguiça  de fazer os exercicios e resolver o problema, só aprende  programar orientado a teste programando e não lendo. Já viu alguém aprender a dirigir lendo um livro de como dirigir? 
 
Quem não deveria fazer o curso
– quem não gosta de programar; 
– quem gosta de respostas prontas;
– quem gosta de seguir passos para resolver um exercicio e achar que aprendeu; 
– quem acha que TDD é coisa de desenvolvedor nerd e é frescura :); 
 
 O que vou ver no curso? 
 – Muito código Java; 
 – problemas para resolver através de unit tests; 
 – entender o ciclo de TDD e ser direcionado para aplicar nos exercicios e problemas existente; 
 – Meter mão na massa do inicio ao fim.
 
 Mais sobre o curso vocês podem conferir aqui
 
 Dúvidas? Comentem 🙂
 
 abracos see ya!!

Resolvendo LazyInitializationException em 5 minutos

Olá Pessoal,

No post de hoje vamos ver como podemos resolver o LazyInitializationException em 5 minutos. Dificilmente um desenvolvedor não passou por essa exceção. Não vou entrar em detalhes sobre o motivo  da exceção LazyInitializationException, até por que já falei em um post aqui no blog, usando a solução com filter.

Lets go…

Na prática

Para mostrar a solução na prática, vou pegar um exemplo simples. Vamos considerar o relacionamento de que um Type  tem muitos Users, veja

@Entity

@Table(name = “type”)

public class Type implements java.io.Serializable { 

private static final long serialVersionUID = 2644022136811709451L; 

private Long id;

private String description;

private Set<User> users = new HashSet<User>(); 

public Type() {

}

@Id

@GeneratedValue

@Column(name = “ID”, unique = true, nullable = false)

public Long getId() {

return this.id;

}

@OneToMany(fetch = FetchType.LAZY, mappedBy = “type”,  targetEntity=User.class)

public Set<User> getUsers() {

return this.users;

}

//getters/setters omitidos

}

User.java

@Entity

@Table(name = “user”, uniqueConstraints = @UniqueConstraint(columnNames = “EMAIL”))

public class User implements java.io.Serializable,Comparable<User> { 

private static final long serialVersionUID = 9108778602728711429L; 

//declaração de variaveis omitidas 

@ManyToOne(fetch = FetchType.LAZY)

@JoinColumn(name = “TYPE_ID”,nullable=false)

public Type getType() {

return this.type;

}

//getters/setters omitidos

} 

Nada de especial até aqui, apenas o relacionamento que já conhecemos.

O problema

Agora que temos o problema, quando o User.java tentar acessar o Type e a conexão já foi fechada, já sabemos que vamos resolver LazyInitializationException. Uma forma para resolver é usando  join fetch, que evitará o problema pelo seguinte motivo:

– Apenas uma consulta será feita e evitamos o problema N + 1;

– A realização da consulta vai deixar de ser Lazy para Eager. Isso é diferente de você mudar de Lazy para Eager.

No DAO

Devemos ter a consulta assim:

public class UserDAO{

public List<User> readAll() {

                //avoiding LazyInitializationException join fetch

                String hql = “select u from User u join fetch u.type”;

                Query query = getCurrentSession().createQuery(hql);

                return query.list();

        }

}

Pronto. Resolvido seu problema com LazyInitializationException. Mas um detalhe importante é que para cada coleção que temos, é uma consulta que devemos ter. Se Type tem uma coleção de acesso, é uma consulta.

Bom é isso. Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!! 

Série CI:Build Automatizado com Jenkins e GitHub

Olá Pessoal,

No último post vimos como conectar o Jenkins com o GitHub. Hoje veremos como automatizar o nosso build, ou seja, se alguma mudança ocorreu no repositório, um novo build é iniciado.

Lets go…

Starting…

Considerando que você tem o cenário do post anterior conforme a imagem a seguir:

 

cijenkinscenario

Clique no projeto MyBookStore e vá em configure.

Em build trigger deixe assim:

buildtriggerjenkins

O que fizemos?

Simples, estamos dizendo que a cada mudança no github vamos precisar rodar um novo build, porém, como estamos rodando localmente o jenkins, não tem como o Github informar ao Jenkins que algo mudou, então faremos o Jenkins verificar a cada 1min se algo mudou no Github. Essa é a forma que temos de fazer isso quando não temos o jenkins em um IP Público.

Feito isso, vá em manage jenkins >> configure system

E em GitHub Web Hook deixamos assim:

githubwebhook

Após inserir seus dados do github e a url do repositório, clique em test credential.

Agora vamos testar e ver se o build vai iniciar automaticamente. Mas antes veremos como estamos:

 

historybookstorebuild

No meu caso tenho o histórico de build acima. É esperado que se algo for alterado no repositório uma nova build seja iniciada, claro que não será de imediato, mas sim cada 1 min.

Vá no seu GitHub e acesse o projeto:

mybookstoregithubjenkins

Aperte a tecla T e você poderá realizar uma pesquisa no GitHub. Procure por store e escolha StoreMatrix.java 

storematrixgithub

É a classe que vamos realizar a alteração e aguardar o Jenkins build. Ao selecionar a classe, clique no botão Edit e adicione o atributo address.

addressaddedstorematrix

Clique no botão commit changes .

Vamos aguardar por 1 min e ver se o jenkins inicia o build. O resultado é como a seguir:

buildqueuejenkinsbookstore

Pronto! Temos agora nosso build automatizado conectado ao jenkins. Simples, não?

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!!