Lucas Teixeira

Olá Pessoal,

Estou invadindo o Blog do meu grande amigo Lucas para postar uma solução que encontrei para um problema no mapeamento de dados de uma base de dados existente. Gostaria, em primeiro lugar, de agradecer o espaço cedido pelo Lucas e parabenizá-lo pelo excelente Blog.

Hoje em dia são poucos os projetos que precisamos desenvolver do zero — criar modelagem, tabelas e etc… — por isso é muito comum depararmos com padrões proprietários que muitas vezes não se “encaixam” na ferramenta de desenvolvimento. Não preciso dizer que não é uma tarefa fácil convencer os desenvolvedores a se adequarem aos novos padrões, então, se não pode com eles, una-se a eles.

Bom, vamos direto ao assunto, no meu projeto atual me deparei com um padrão que utiliza ‘S’ e ‘N’ para o mapeamento de propriedades booleanas no banco de dados Oracle. Na pesquisa que realizei encontrei várias pseudo-soluções mas a única que atendeu 100% as necessidades foi a implementação de um tipo de dados do Hibernate.

Abaixo a implementação da classe SNUserType, não tem segredo é apenas a implementação da interface org.hibernate.usertype.UserType. Salve este código no pacote persistence na pasta de src/groovy do seu projeto Grails.

package persistence;

import org.hibernate.*;
import org.hibernate.usertype.*;
import java.sql.*;
import java.util.*;
import java.io.Serializable;

public class SNUserType implements UserType {

   def SQL_TYPES = [Hibernate.YES_NO.sqlType()];

   public int[] sqlTypes() {
      return SQL_TYPES;
   }

   private Class targetClass;

   public void setParameterValues(Properties params) {
      String targetClassName = params.getProperty("targetClass");
      try {
         targetClass = Class.forName(targetClassName);
      } catch (ClassNotFoundException e) {
         throw new HibernateException("Class " + targetClassName + " not found ", e);
      }
   }

   public Class returnedClass() {
      return targetClass;
   }

   public boolean isMutable() {
      return false;
   }

   public Object deepCopy(Object value) {
      return value;
   }

   public Serializable disassemble(Object value) {
      return (Serializable) value;
   }

   public Object assemble(Serializable cached, Object owner) {
      return cached;
   }

   public Object replace(Object original, Object target, Object owner) {
      return original;
   }

   public boolean equals(Object x, Object y) {
      if (x == y)
         return true;
      if (x == null || y == null)
         return false;
      return x.equals(y);
   }

   public int hashCode(Object x) {
      return x.hashCode();
   }

   public Object nullSafeGet(ResultSet rs, String[] names, Object owner) throws SQLException {
      String value = rs.getString(names[0]);
      if ("S".equals(value))
         return true;
      else
         return false;
   }

   public void nullSafeSet(PreparedStatement ps, Object value, int index) throws HibernateException, SQLException {
      if (value == null) {
         ps.setNull(index, Hibernate.YES_NO.sqlType());
      } else {
         if((Boolean)value) {
            ps.setString(index, "S");
         } else {
            ps.setString(index, "N");
         }
      }
   }
}

Pronto, agora tudo que você precisa fazer é utilizar o novo tipo de dados no mapeamento de suas classes de domínio.

class Pessoa {

   String nome
   Boolean ativo

   static mapping = {
      ativo type: "persistence.SNUserType"
   }

}

Com isso, resolvi o problema de integração e concluímos este post.

Um abraço

Volnei

Como postado antes, ontem falei sobre Grails no SESTINFO – “Grails: Java produtivo e divertido”, evento aberto da UMESP (Universidade Metodista de São Paulo).
O evento foi incrível, com muita gente presente. O último número que recebi é que tinham 98 pessoas na sala assistindo e mais dois professores. Ainda depois do início da palestra cerca de 15 a 20 pessoas chegaram mas não puderam entrar pelo limite de pessoas na sala.

Pra quem não pode estar presente, comecei a apresentação falando de groovy e fazendo um paralelo de uma aplicação Java e a mesma em Groovy, passo-a-passo mostrando os benefícios e vantagens que o groovy pode trazer para o desenvolvimento (o antigo caso do seletor de palavras).
Tentei deixar bem claro o tempo inteiro que o importante é gastarmos tempo *PENSANDO* em resolver o problema e não tentando aprender e entender como a linguagem de programação funciona.

Logo depois, passei por vários pontos do Grails, tentando mostrar como ele trazia os benfícios do Groovy para o desenvolvimento web. Passei pelo GORM (mapeamento objeto-relacional dinâmico), plugins, convenções e vários outros pontos. Pra encerrar a parte teórica, deixei alguns links e sites interessantes para que o pessoal pudesse consultar além de oferecer para os presentes cupons de desconto para a GroovyMag, revista focada em desenvolvimento Groovy e Grails.

Ao fim, apresentei uma aplicação simples, desenvolvida em bem pouco tempo que funcionava como um ‘twitter wall’, ou seja, fazendo buscas automaticamente no twitter de palavras previamente cadastradas, inclusive capturando automaticamente tweets do pessoal que estavam assistindo a palestra e twittando… :)

Bom, como eu já falei, foi muito bom, e além de satisfeito, fiquei muito agradecido, então não posso deixar de agradecer:
Principalmente ao Prof. Mauro Schneider (@muschneider), professor da Universidade que me fez o convite e viabilizou tudo isso, a Universidade não só o meu agradecimento, mas também os meus parabéns pelo ótimo evento. Aos meus amigos que me confirmara, e foram me apoiar e ajudar, Emerson (@erbernardino), Paulo (@paulosuzart), Leonardo (@leonardofigs), Rafael (@rafaelfelini), Luca (@lucabastos) e Jailton (@jailton). Ao Jailton, não só pela presença, mas também pelo apoio divulgando o evento na lista do SOUJava.

Pra quem quiser, a apresentação segue abaixo. E também 2 repositórios que criei no github, um com os fontes do projeto apresentado, e outro com a apresentação em HTML.

Repositório da apresentação: http://github.com/lucastex/slides-grails-umesp
Repositório dos fontes do projeto: http://github.com/lucastex/projeto-grails-umesp

Pra quem estará em São Paulo na próxima terça-feira, eu irei apresentar uma palestra sobre Grails na SESTINFO – Semana de Estudos em Tecnologia da Universidade Metodista de São Paulo.

O título da palestra será – “Grails – Java produtivo e divertido” e a entrada é liberada para quem quiser assistir. Vou falar de Groovy e Grails além da comunidade envolvida em torno dessas tecnologias. E ao final da apresentação, vou fazer algum hands on com o pessoal, desenvolvendo uma aplicação live com todos.

Divulgue em suas listas de discussões, empresa, amigos e inimigos, aproveitem que a entrada é liberada!

Data: 25 de maio
Horário: A partir das 19:00
Local: Universidade Metodista
Endereço: Rua Alfeu Tavares, 149 – Rudge Ramos – São Bernardo do Campo – SP

Mapa: http://maps.google.com.br/maps?f=q&source=s_q&hl=pt-BR&geocode=&q=Rua+Alfeu+Tavares,+149+Rudge+Ramos+-+S%C3%A3o+Bernardo+do+Campo+%E2%80%93+SP&sll=-23.581689,-46.642769&sspn=0.020551,0.046756&ie=UTF8&hq=&hnear=R.+Alfeu+Tavares,+149+-+Rudge+Ramos,+S%C3%A3o+Bernardo+do+Campo+-+S%C3%A3o+Paulo,+09641-000&ll=-23.609924,-46.548729&spn=0.16437,0.37405&z=13&iwloc=A

Depois da palestra, vou divulgar os slides e os fontes do hands on aqui no blog.

Ajude a divulgar, retwittando esta mensagem: http://twitter.com/lucastex/status/14333780136

[Atualizado!]

Vou distribuir uma edição grátis da Groovy Magazine (groovymag.com) para cada pessoa presente no local, compareça!

Acabei de lancar um novo plugin grails.

Este calcula o valor do envio de uma encomenda através dos Correios. Contempla SEDEX, SEDEX 10, SEDEX a cobrar e outros. O texto explicativo está bem simples e legal, e está no github junto com os fontes:

http://github.com/lucastex/correios-br

Mesmo os fontes no github, você pode instalar o plugin usando o comando padrão do grails:

grails install-plugin correios-br

Deem uma olhada nos docs do github, vale a pena!

Recebi uma pergunta esses dias por aqui.

Lucas,
gostaria de saber como trabalhar com arquivos .properties pra conexão com o banco de dados.
No Grails a gente nota que a conexão fica no código-fonte (DataSorce.class)…
Estou tentando descobrir como faço para ter um arquivo de propriedade com os parametros da conexão. Caso eu precise apontar para outro banco, não terei que recoompilar tudo.

production {
   dataSource {
      jndiName = "<nome_datasource>"
   }
}

GSolr, é o nome do plugin de solr que estamos fazendo de solr para grails. Para quem quiser acompanhar o trabalho, o repositório está no github: http://github.com/lucastex/gsolr.

Uma coisa que já está feita é a leitura da configuração do gsolr e a declaração mágica de beans, um para cada servidor solr que estiver configurado. Exemplificando, vamos imaginar que a configuração esteja declarando três servidores Solr que serão consultados:

gsolr {
   solr {
      produtos {
         (...)
      }
      noticias {
         (...)
      }
      usuarios {
         (...)
      }
   }
}

Particularmente, achei bem interessante usar o nome da closure para o nome do servidor ao invés de termos um atributo name = produtos :)
A mágica legal mesmo, é que o plugin vai ler esta configuração quando a aplicação for para o ar, e depois disso irá declarar / criar beans spring dinâmicamente, usando a Spring DSL. E os beans vão ter no nome a declaração feita na closure do usuário.

Ou seja, para os servidores solr declarados acima, o plugin irá declarar os Spring Beans produtosGSolr, noticiasGSolr e usuariosGSolr .

Desta maneira, vamos garantir que se você quiser o usar o plugin, o processo como um todo ficará o menos intrusivo possível, e você poderá usar os métodos (de pesquisa e outros) do GSolr apenas injetando o bean do servidor Solr que você quiser.

class PesquisaService {
   def noticiasGSolr

   def pesquisar = {
      (...)
   }
}

Achei no mínimo, muito prático. Tudo isso graças a Spring DSL que temos em groovy. Com um pouco mais de tempo, coloco o procedimento passo a passo para declarar os beans desta maneira. Enquanto isso, conheça um pouco mais sobre a Spring DSL aqui, ou veja o código fonte aqui e também aqui.

Tem alguma idéia ou sugestão para o plugin? Deixe um comentário!

Estamos fazendo o desenho do plugin do Solr para o Grails, e precisei das libs do solr/lucene. Dessa vez quis fazer diferente e usar o gerenciamento de dependências que o grails traz usando o ivy. Pra mim, que nunca tinha trabalhado com ivy antes, foi bem simples até.

Bastou eu levantar os grupos/artifactsId e versão do solr-core e do solrj (1.4) e adicionar no meu BuildConfig.groovy. Consegui estas informações no próprio wiki do solr, nesta página: http://wiki.apache.org/solr/Solrj#Maven

Depois disso, bastou adicionar um repositório para buscar os jars

repositories {
    mavenRepo "http://mirrors.ibiblio.org/pub/mirrors/maven2"
}

E declarar as dependências que eu precisaria em runtime:

dependencies {
    runtime 'org.apache.solr:solr-core:1.4.0'
    runtime 'org.apache.solr:solr-solrj:1.4.0'
}

Tá rolando uma discussão legal na lista “grails-users” sobre Solr.

Estamos levantando alguns pontos que seriam essenciais e interessantes para um plugin grails que cuidasse disso. Se você gosta também de Solr, ou está interessado, acompanhe os e-mails na Grails-Users ou no nabble aqui.

Você usa solr? O que acha interessante nele que deva existir em um plugin grails?

Neste fim de semana quis fazer alguns testes pela primeira vez com uma aplicação grails no jboss.

Já tinha acompanhado na grails-users que existem alguns problemas para efetuar o deploy, e para cada um deles, uma sequência de passos obscuros para fazer o deploy acontecer com sucesso. Minha versão de grails neste procedimento é a 1.2.1 e do JBoss é a 5.1.0.GA

Efetivamente, o que acontece é que jboss traz junto com suas common libs vários jars que são empacotados juntamente com a sua aplicação quando você utiliza o comando grails war.

Existem alguns workarounds na internet que te mostram como modificar o BuildConfig.groovy (arquivo que define propriedades do empacotamento de sua app) para que após montar a estrutura de arquivos que irão ser empacotados, remova estes arquivos (principalmente o log4j onde o problema é mais aparente) do chamado stagingDir e os deixe de fora do pacote final.

Particularmente, achei a solução um tanto quanto diferente e acabei achando no FAQ do Grails e depois com mais detalhes nesta página uma solução menos intrusiva ao pacote, que é definir a prioridade de carregamento dos jars da aplicação.

Bom, para isso, precisamos criar um arquivo jboss-web.xml dentro do diretório WEB-INF de nossa aplicação que irá mostrar ao jboss que queremos “blindar” nossa aplicação para utilizar os jars que estão dentro de seu lib, e que estes por sua vez não deverão ser sobrescritos pelos jars do classpath do servidor. O conteúdo do arquivo segue abaixo:

<jboss-web>
   <context-root>/projeto</context-root>
   <class-loading java2ClassLoadingCompliance="false">
      <loader-repository>
         projeto:archive=projeto.war
         <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository>
   </class-loading>
</jboss-web>

Na tag context-root estamos apenas aproveitando que a aplicação terá seu arquivo de configuração específico para o jboss e definindo o contexto em que ela será publicada. Nas tags seguintes pedimos para o jboss criar o nosso classloader isolado, com o nome “projeto:archive=projeto.war”. Com este nome (que deve ser único, por isto leva em consideração o nome do projeto), garantimos que as classes pedidas pelo nosso projeto serão procuradas ali, e caso não encontradas, nos classpaths seguintes (common/lib, depois no tomcat).

Basicamente isto seria suficiente para conseguir que o projeto rodasse sem problemas. Porém no meu cenário de versões (grails 1.2.1 e jboss-5.1.0.GA) existe outro ponto de conflito. O Hibernate Validator que está junto ao jboss também difere em versão e gera conflito com o grails. Neste caso a solução é ainda mais interessante e simples que a anterior.

Para resolver o problema no deploy que indica claramente problema de versão no Hibernate Validator, basta que você faça o download da última versão deste jar (no meu caso, 4.0.2-GA) nesta url: https://www.hibernate.org/30.html. Depois disto, resta apenas colocar o jar do hibernate validator dentro da pasta <jboss_home>/common/lib.

Pronto, a aplicação está rodando e funcional dentro do jboss!

10:36:32,815 INFO  [[/projeto]] Initializing Spring root WebApplicationContext
10:36:41,155 INFO  [[/projeto]] Initializing Spring FrameworkServlet 'grails'

PS: Vale lembrar que o arquivo jboss-web.xml é padrão para arquivos war, se você quiser configurar a ordem do classpath para aplicações ear ou sar, consulte o link acima para entender as diferenças.

Uma situação que acontece muito, é a reutilização das funções de taglibs dentro dos controllers de sua aplicação grails. Isso é muito fácil de se fazer, basta chamar o método usando o objeto com o nome do namespace da taglib.
Ou seja, para usar dentro do controller a função de formatação de números, definida pela função formatNumber (taglib já no core do grails), é só fazer a chamada assim:

def myAction = {
render g.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])
}

Esta função é equivalente a chamar a taglib de dentro de um gsp da seguinte maneira:

<g:formatNumber number="5000.234" type="number" maxFractionDigits="2" />

Mas quando precisamos fazer isto, por exemplo, dentro de um service, encontramos um probleminha chato, as taglibs não são injetadas automaticamente. Para contornar essa “situação“, temos que buscar a taglib manualmente, da seguinte maneira:

def myTag = grailsApplication.mainContext.
            getBean('org.codehaus.groovy.grails.plugins.web.taglib.ApplicationTagLib')
def value = myTag.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])

Ahhh, para isso não se esqueca de injetar o objeto da grailsApplication da seguinte maneira

class MeuService {
   def grailsApplication
   (...)
}

Bin-go.