Lucas Teixeira

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.

Me deparei com a seguinte situação em uma aplicação construída usando Grails.

O sistema gravaria o conteúdo de um arquivo (plain xml mesmo) dentro do banco de dados, para evitar dependências com filesystem. Mas este arquivo também precisaria ser lido posteriormente. A solução que estava disponível, era alguma coisa mais ou menos assim:

def arquivo = Arquivo.get(params.id) //recupera o arquivo da base
render arquivo.texto

Legal, desta maneira (bem simples até), o conteúdo deste texto seria renderizado na página para o usuário poder salvá-la.

Imaginei que isto pudesse ser incrementado um pouco, e percebi que fazer com que o usuário tivesse que salvar a página (que continha apenas o XML) poderia se tornar um tanto chato com o passar do tempo. Resolvi alterar a action para devolver o texto em anexo ao response. Isso mesmo, com a caixinha para poder salvá-lo.

Olha que simples:

def arquivo = Arquivo.get(params.id) //recupera o arquivo da base
response.setContentType "text/xml"
response.setHeader "Content-Disposition", "attachment;filename=\"${arquivo.nome}.xml\""
response << arquivo.texto

Simples, colocando a instrução no header para que a “disposição” da resposta seja “attachment” (anexo), o browser ao invés de renderizar apenas o conteudo, retorna um arquivo com este texto.

Graças ao ótimo suporte de internacionalização que o grails nos proporciona, podemos alterar o idioma corrente da app passando apenas o parametro lang na URL. Com isso, o locale é definido para o usuário e se sua aplicação recupera as mensagens com o g:message ou outros recursos de i18n, usará o locale indicado.

Caso queira definir um locale default para sua app, basta sobrescrever o bean localeResolver no seu beans.groovy como abaixo:

beans = {
  localeResolver(org.springframework.web.servlet.i18n.SessionLocaleResolver) {
    defaultLocale = new Locale("pt", "BR")
    java.util.Locale.setDefault(defaultLocale)
  }
}

Sim, estou trazendo aos poucos tópicos que estavam em meu outro blog, blog.lucastex.com, dê uma passada por lá.

Hum, reportando uma situação no mínimo inusitada que tive por aqui.

Acabei descobrindo, da maneira ruim, que no Grails, quando lêmos a configuração da aplicação (Config.groovy) através da referência grailsApplication.config estamos manipulando uma variável passível de alterações, ou seja, qualquer atributo que você recuperar de lá, e modificar, assim estará para toda a execução.

Na minha situação, eu mantinha uma lista de e-mails lá no arquivo de configuração para que quando disparado, eu pudesse enviar o e-mail a estes destinatários somados ao e-mail do usuário, que tinha acabado de ser inputado no formulário. Tinha algo assim:

contato.destinatarios = ["email1@xpto.com", "email2@xpto.com", "email3@xpto.com"]

E dentro do controller, usando o mail plugin (leia este post sobre o mail plugin), executava o seguinte trecho de código:

def destinatarios = grailsApplication.config.contato?.destinatarios?.toArray()
destinatarios << params.email
sendMail {
    to destinatarios
    subject "Contato ..."
    body "......"
 }

Ou seja, quando eu pegava a referência dos destinatários do Config, eu mantinha essa referência em ‘destinatários’. Quando eu adicionava neste array o destinatário que vinha do formulários “params.email”, eu alterava a *instância* e referência da configuração da aplicação, e aquele e-mail ali ficava.

Resultado, no primeiro contato, receberam o e-mail a lista de destinatários e o primeirocontato@xpto.com, na segunda execução, todos eles da configuração, o primeirocontato@xpto.com e também o segundocontato@xpto.com foram copiados.

E assim sucessivamente.

Vivendo e aprendendo, tomem cuidado com isso!

Ontem (dia 09/01) fizemos o lançamento de um site que desenvolvemos usando Groovy e Grails, um desafio e tanto, pela responsabilidade de colocar o sistema no ar e pelo timing do projeto. Todo o site e a integração com o sistema legado (onde algumas informações ainda estão sendo gerenciadas), tiveram que sair do simples “create app” para produção em 2 meses. Esse é também o grande motivo para a falta de tempo de postar mais por aqui.

Trata-se dos sites http://www.imoveisnomorumbi.com.br e http://www.imoveisnopanamby.com.br, site de duas imobiliárias do mesmo grupo, que negocia imóveis de alto padrão nestes dois bairros.

Algumas informações interessantes sobre o projeto:

Tecnologia e Infraestrutura: O site antigo usava SQLServer como banco de dados e tecnologia ASP. Como usamos Groovy e Grails, por trás temos uma JVM Java em execução, e o banco de dados, o bom e velho MySQL.

Antes, para suportar o ASP, o IIS era usado como web server, e agora Um apache balanceia as requisições aos dois Tomcats. Tudo isto está deployado e rodando em um Cloud Server da Locaweb, por opção do cliente, onde já mantinha a conta antiga.

Integração com o sistema legado: Para a integração do modelo de dados antigo e o novo modelo, construímos rotinas de importação dos dados usando Groovy SQL, uma maneira  fácil, muito fácil, de fazer rotinas em banco de dados.

Plugins utilizados: Ahhh, os bons e velhos plugins do Grails, não canso de dizer que esta é a melhor parte do Grails! Foram usados os plugins:

Grails-Mail, para envio dos e-mails e formas de contato do site
Grails-Acegi, para autenticação e segurança
Grails-Cookie, para manipulação dos cookies do cliente
Grails-Navigation para criação de menus/submenus da interface administrativa
Grails-RichUi para alguns componentes gráficos como auto-complete e nuvem de tags
Grails-RuntimeLogging, um ótimo plugin para moder trabalhar com o nível de log de cada artefato (controller, service, etc), da app em runtime
Grails-Settings para algumas parametrizações da aplicação.

E com certeza, se eu tivesse pesquisado com um pouco mais de tempo, teria usado outros plugins para evitar algum trabalho que tenha feito na mão. E é claro, além disso, bastante (mesmo) jquery, ajax e json.

É isso, qualquer dúvida sobre o projeto, como aconteceu, soluções e problemas, basta comentar!

Obrigado a todos!