Destaquenet blog

Integração Contínua de aplicações Python com Hudson

Daniel Martins — Mon, 27 Oct 2008 12:00:24 +0000

No começo deste mês eu dei dicas sobre como usar o Fabric para automatizar o build e o deployment de aplicações Python.

Essa automatização por si só já quebra uma árvore, mas ela possibilita ainda o uso de Integração Contínua, uma prática extremamente importante que costuma ajudar muitas equipes a manter seus projetos nos trilhos. Para mais informações sobre Integração Contínua, eu recomendo a leitura deste artigo, até porque este post terá um enfoque mais prático.

Neste texto será mostrado como configurar um projeto Python no Hudson, um servidor de Integração Contínua muito simples de configurar e utilizar. O sistema de controle de versões que eu utilizo aqui é o Git, mas usuários de outros sistemas também poderão achar este texto útil.

Baixando o Hudson

Acesse o site do Hudson e baixe o arquivo .war através do link disponível na página principal. Quando o download terminar, basta rodar o comando abaixo para subir o servidor na porta 8080:

java -jar hudson.war

Tela inicial do Hudson

Perca uns cinco minutos dando uma navegada no Hudson para ter uma idéia melhor do que é possível de ser feito com ele.

Hudson e plugins

O Hudson vem com suporte a Maven e Ant, duas das mais populares ferramentas para build de aplicações Java. Mas não se engane: o Hudson pode ser aproveitado em praticamente qualquer projeto, independente da linguagem e dos frameworks utilizados.

As funcionalidades do Hudson podem ser estendidas através de plugins, sendo que neste artigo utilizaremos dois deles: o Git Plugin, necessário para que o Hudson consiga trabalhar com repositórios Git, e o Violations, que consegue interpretar a saída de diferentes verificadores de código (dentre eles o pylint, um analisador de código Python!) e exibir informações a respeito da qualidade do código-fonte.

Para instalar esses plugins, basta acessar a tela de gerenciamento de plugins, marcar o Git Plugin e o Violations, e confirmar:

Instalando os plugins

Assim que a instalação terminar, reinicie o Hudson.

Integrando testes escritos com PyUnit ao Hudson

Apesar de existirem várias opções para criação e execução de testes unitários para Python, o PyUnit costuma ser o mais usado pelo fato de já estar incluído na distribuição padrão do Python.

Quem já fuçou no código do PyUnit sabe que ele define apenas um TestRunner, o TextTestRunner. O que este TestRunner basicamente faz é gerar em um fluxo qualquer (geralmente no sys.stderr) uma saída parecida com a seguinte:

.....
----------------------------------------------------------------------
Ran 5 tests in 0.067s

Apesar de eu me contentar com essa saída mais simples, bom, ferramentas como o próprio Hudson não se contentam; elas preferem algo como o bom e velho XML, que, convenhamos, é muito mais fácil de parsear.

Perdi algumas horas na Internet procurando por um TestRunner que conseguisse gerar arquivos XML no mesmo formato que os gerados pelo Ant e Maven, mas não encontrei nenhuma opção que fosse minimamente confiável. Por isso, eu tomei a liberdade de escrever meu próprio TestRunner: XMLTestRunner. O código deste “projeto”, disponibilizado no Github, contém instruções de uso e scripts de exemplo. Clonem e forkem à vontade!

Antes de prosseguirmos, baixe o módulo xmlrunner.py do site do projeto e o copie em algum lugar dentro do seu PYTHONPATH.

Integrando um projeto Python no Hudson

Para não perdermos tempo criando do zero um projeto de exemplo em Python, eu mostrarei como fazer para integrar o próprio XMLTestRunner com o Hudson.

Abra o console administrativo do Hudson e clique no link New Job:

Criando um projeto "free-style"

Na próxima tela, precisamos configurar o Job com os dados necessários:

Configuração de projeto

Isso é tudo! Confirme as alterações e clique no link Build now. Aguarde alguns segundos enquanto o projeto é baixado do repositório Git e testado:

Exemplos de builds feitos pelo Hudson

Relatório de execução de testes

Análise de código feita pelo pylint

Como disparar o build de forma automática?

Uma vez que o projeto tenha sido configurado corretamente, basta um clique do mouse para que o Hudson faça todo o trabalho sujo. O problema agora é lembrar de fazer o build sempre que alguém modificar código no repositório.

Felizmente, temos duas opções para nos livrar de mais essa tarefa manual: a primeira seria configurar, nas propriedades do Job, uma expressão Cron que indique de quanto em quanto tempo o build deve ser feito; a segunda alternativa é apenas disparar o build quando alguém modificar código no repositório.

Como acontece com outros sistemas de controle de revisão, o Git possui hooks que nos permite executar ações em determinados momentos. Esses hooks nada mais são do que scripts executáveis localizados no diretório .git/hooks.

Mas enfim, quando disparar o build? Se o repositório Git e o servidor Hudson não são capazes de se comunicar diretamente, talvez a única alternativa seja disparar o build periodicamente. Para isso, você deve configurar um ou mais Build Triggers, na tela de configuração do Job.

Entretanto, se você mantém o repositório Git e o servidor Hudson na mesma máquina, ou mesmo em máquinas diferentes mas capazes de se comunicar via rede, podemos considerar a utilização dos hooks como ferramenta de integração entre o repositório Git e o Hudson.

Agora a pergunta que não quer calar: como integrar o Git e o Hudson? Bem, isso ficará como exercício para o leitor.

Dicas:

O Hudson disponibiliza uma API através da qual se pode agendar builds, alterar as configurações do Job, criar Jobs, entre outras coisas.
Para conhecer os hooks oferecidos pelo Git, consulte a documentação.

Conclusão

Já faz algum tempo que eu venho utilizando o Hudson para integrar projetos Java, e esta ferramenta vem se mostrando muito útil no meu dia-a-dia. Só quem pratica Integração Contínua sabe o quanto é complicado não contar com a segurança que ela proporciona ao desenvolvimento.

O problema, no entanto, começou quando eu optei pelo Python em vez do Java em certos projetos. Obviamente, eu queria aproveitar o ambiente de Integração Contínua que eu já utilizava, o que foi bastante complicado já que o PyUnit, framework de testes que eu costumo utilizar, não oferece uma forma de gerar relatórios XML, da mesma forma que Ant e Maven fazem.

Depois de estudar o funcionamento interno do PyUnit, eu decidi implementar um TestRunner que fosse capaz de gerar arquivos XML no formato esperado pelo Hudson. Deu um bocado de trabalho, é verdade, mas pelo menos agora eu consigo utilizar os excelentes relatórios gerados pelo Hudson para acompanhar a execução dos meus testes PyUnit.

Como o Brasil é grande, seria burrice achar que eu fui o único a enfrentar esse tipo de dificuldade. Por esse motivo, eu resolvi escrever este texto e, quem sabe, ajudar àqueles que enfrentam um problema semelhante.

Rails Summit Latin America ‘08: eu vou!

Daniel Martins — Mon, 13 Oct 2008 03:01:41 +0000

Todos já devem estar sabendo, mas vale a pena repetir que irá rolar em Sampa, nos dias 15 e 16 de Outubro, o evento Rails Summit Latin America.

Minha expectativa em relação a este evento em particular é muito boa. Apesar de já terem ocorrido outros eventos dedicados ao Ruby on Rails aqui no Brasil, os organizadores desse evento em particular resolveram levar a coisa toda a um outro nível.

Citando o site do evento:

O Rails Summit Latin America surge para completar a agenda dos grandes eventos mundiais de Ruby on Rails™. Inspirado na RailsConf americana que reúne cerca de 2.000 desenvolvedores e tomadores de decisão, o Rails Summit Latin America trará os principais palestrantes e especialistas no assunto do mundo inteiro incluindo participação especial do criador do Ruby on Rails™, David Hansson.

Com diversos palestrantes internacionais e empreendedores brasileiros, o evento será referência sobre o assunto na América Latina, trazendo o que há de melhor na plataforma para o Brasil.

Para quem não se inscreveu, corra que ainda dá tempo. (eu acho!)

Nos vemos por lá!

Deployment de aplicações Python com Fabric

Daniel Martins — Sun, 05 Oct 2008 10:00:05 +0000

Uma coisa é fato: subir uma nova versão de uma aplicação é um procedimento que, se feito manualmente, costuma demandar tempo precioso, independente do tamanho da aplicação e dos frameworks utilizados no projeto. Não há o que discutir.

Na verdade, ninguém parecia se importar em automatizar tarefas “mecânicas” como o deployment, coisa que mudou de figura ao passo que metodologias ágeis — juntamente com técnicas como Integração Contínua — passaram a se tornar populares. Desde então, algum esforço vem sendo investido para criar ferramentas para automatização de muitas dessas tarefas.

Fabric: ferramenta Python para deployment

Apesar de já ter utilizado algumas dessas ferramentas no desenvolvimento de projetos em Java, plataforma na qual eu possuo uma experiência maior, eu ainda não conhecia nenhuma ferramenta em Python que me permitisse automatizar o deployment de uma aplicação.

Como eu estava começando a ficar de saco cheio de ter que atualizar os arquivos de uma aplicação Django via SCP, eu resolvi que já era hora de ir atrás de alguma ferramenta que me ajudasse a automatizar esse processo. Finalmente, depois de muita procura, eu encontrei Fabric, uma ferramenta mais ou menos parecida com um Capistrano “capado”.

A instalação do Fabric é bem simples para quem costuma usar o easy_install:

daniel ~ $ sudo easy_install Fabric

Basta executar esse comando para que os fontes da última versão do Fabric (0.0.9 no momento da publicação deste texto) sejam baixados e instalados.

Atenção: Quem utiliza máquinas Windows, provavelmente precisará do Cygwin, já que o Fabric assume o uso de ambientes Unix.

Fabric a 3.000 pés

Neste momento você já deve conseguir executar o comando fab no terminal. Se tudo correu bem até aqui, estamos prontos continuar.

Vamos começar criando o arquivo fabfile.py no diretório-raíz da aplicação. Coloque o seguinte conteúdo neste arquivo:

set(
    project = 'project_name',
 
    package     = '$(project).zip',
 
    # Remote servers
    fab_user    = 'usuario_ssh',
    fab_hosts   = ['servidor1.com', 'servidor2.com'],
)
 
 
def deploy():
    "Deploy the application to the production servers."
    build()
 
def build():
    "Build the application."
    prepare()
 
def prepare():
    "Prepare the build directory."
    clean()
 
def clean():
    "Remove the build directory."
    pass

Cada método definido no arquivo é equivalente a uma task do Capistrano. No início temos o método set que nos permite configurar as variáveis necessárias para o script. Veja que, neste método set, indicamos na variável fab_hosts os servidores nos quais os comandos remotos devem ser executados.

Ok, tente executar o comando fab no terminal, no mesmo diretório onde se encontra o arquivo fabfile.py. Se tudo correr bem, você receberá a seguinte saída:

daniel ~  $  fab
   Fabric v. 0.0.9, Copyright (C) 2008 Christian Vest Hansen.
   Fabric comes with ABSOLUTELY NO WARRANTY; for details type `fab warranty'.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `fab license' for details.

No commands given.
Available commands are:
   build    : Build the application.
   clean    : Remove the build directory.
   deploy   : Deploy the application to the production servers.
   help     : Display Fabric usage help, or help for a given command.
   license  : Display the Fabric distribution license text.
   list     : Display a list of commands with descriptions.
   prepare  : Prepare the build directory.
   set      : Set a Fabric variable.
   shell    : Start an interactive shell connection to the specified hosts.
   warranty : Display warranty information for the Fabric software.
Done.

Veja que as tasks que criamos estão disponíveis para serem executadas via linha de comando. Para executar as tasks clean e deploy, por exemplo, utilizaríamos o seguinte comando:

daniel ~  $  fab clean deploy

Simples, não é? Antes de vermos um exemplo de script completo, vamos conhecer os três principais métodos utilizados em scripts Fabric: local, run e put:

local: Serve para executar comandos na máquina local. Ex: local('mkdir build');
run: Igual ao local, mas executa os comandos nas máquinas remotas (indicadas na variável fab_hosts);
put: Envia um arquivo para as máquinas remotas. Ex: put('arquivo.zip', '/home/user/app.zip').

Antes de prosseguirmos, vamos voltar a olhar a chamada ao método set, no início do código. Nele, eu usei um recurso do Fabric conhecido como lazy evaluation. No caso, temos a variável package que recebe o valor '$(project).zip'. Esse $(project) indica que queremos que o valor da variável project substitua o placeholder. Isso permite que variáveis sejam interpoladas umas dentro das outras.

Por exemplo, se dentro de uma task executarmos o comando local('rm $(package)'), isso significa que o Fabric irá parsear a string, transformando-a em 'rm project_name' para só então executar tal comando na máquina local.

Como veremos a seguir, eu utilizei este recurso exaustivamente no meu script. Em caso de dúvidas, consulte a documentação do Fabric.

Finalmente, o script completo!

Antes de mostrar o script que eu venho utilizando para fazer o deployment de uma aplicação Django, veja como seus arquivos e diretórios estão organizados: (isso deve ajudar a entender melhor o script)

Estrutura do projeto

E, finalmente, o script:

set(
    project = 'destaqueweb',
 
    # Build output directory
    build_path  = 'build',
    package     = '$(project).zip',
 
    # Media
    media_src   = 'media',
    media_root  = 'public_html',
    media_path  = '$(media_root)/$(project)/$(media_src)',
    media_build = '$(build_path)/$(media_path)',
 
    # Application code
    app_root  = 'wsgi_apps',
    app_path  = '$(app_root)/$(project)',
    app_build = '$(build_path)/$(app_path)',
 
    # Remote servers
    fab_user    = 'destaquenet',
    fab_hosts   = ['destaquenet.com'],
 
    destination = '/home/destaquenet',
    touch       = '$(destination)/$(media_root)/$(project)/index.wsgi',
)
 
def deploy():
    "Deploy the application to the production server."
    build()
 
    # Upload the zip file
    put('$(build_path)/$(package)', '$(destination)/$(package)')
 
    # Extract the zip file
    run('cd $(destination); unzip -uo $(package); rm $(package)')
 
    # Reload the application
    run('touch $(touch)')
 
def build():
    "Build the application."
    prepare()
 
    # Copy application files to the build directory
    local('cp -R $(project)/* $(build_path)/$(app_path)')
    local('cp -R $(media_src)/* $(build_path)/$(media_path)')
 
    # Remove unecessary files
    local('find $(build_path) -name *.pyc -delete')
    local('find $(build_path) -path *upload* -delete')
    local('find $(build_path) -path *fixtures* -delete')
 
    # Create the zip file
    local('cd $(build_path);zip -r $(package) $(media_root) $(app_root)')
 
def prepare():
    "Prepare the build directory."
    clean()
 
    local('mkdir -p $(media_build)')
    local('mkdir -p $(app_build)')
 
def clean():
    "Remove the build directory."
    local('rm -fR $(build_path)')

Este código deve ser facilmente entendido por quem tem trabalha com uma certa facilidade no terminal.

Basicamente o que o código faz é organizar os arquivos da aplicação para que estes fiquem dispostos da mesma forma utilizada pelo servidor de produção, enviar os arquivos dentro de um pacote ZIP para os servidores e descompactá-los no local correto, além de executar um touch no script WSGI para que o Apache recarregue a aplicação.

Tudo pronto. Agora basta executar fab deploy no terminal para subir a aplicação para o(s) servidor(es) desejado(s).

Fabric e ambiente de homologação

Uma coisa que vem se tornando comum é o uso de diferentes ambientes onde uma aplicação costuma ser implantada (ex: ambiente de homologação). Se sua empresa costuma trabalhar dessa forma, o Fabric ainda pode te ajudar.

Por exemplo, vamos supor que sua empresa possua um servidor de produção e um servidor de homologação. Podemos, então, adequar o script para que ele possa trabalhar com ambos os ambientes:

set(
    # ...
    fab_user = 'production',
    fab_hosts = ['app.com']
)
 
def staging():
    # deploy to staging servers
    set(fab_user = 'staging', fab_hosts = ['staging.app.com'])
 
# other tasks...

Fazendo as mudanças mostradas acima, para executar o deployment no ambiente de homologação basta rodar o comando fab staging deploy; o deployment em ambiente de produção continua disponível através do comando fab deploy.

Isso é possível pois podemos substituir o valor de uma variável (ou configurar novas variáveis) a qualquer momento, através do método set. Então, quando executamos o comando fab staging deploy, o Fabric executa a task staging, substituindo o valor das variáveis fab_user e fab_hosts, fazendo com que os comandos contidos na task deploy sejam executados nos servidores de homologação em vez de nos servidores de produção.

Seaside: um framework web de verdade

Daniel Martins — Wed, 01 Oct 2008 01:44:39 +0000

Provavelmente isso não é novidade para alguns de vocês, mas já faz algum tempo que eu venho me aventurando pelo incrível mundo do Smalltalk. Dando prosseguimento à esta saga, tenho o orgulho de anunciar a minha próxima vítima: o framework Seaside!

O Seaside é um impressionante framework web escrito em Smalltalk focado no desenvolvimento de ~~sites~~ aplicações stateful. Mesmo conhecendo muito pouco a respeito do seu funcionamento — até então, nada além de um mísero hello world — resolvi tentar criar uma aplicação que realmente fizesse algo a mais do que simplesmente escrever um texto na tela.

A experiência foi muito boa, mas poderia ter sido melhor se o projeto contasse com uma documentação decente. O código do framework propriamente dito é muito bem documentado e é possível aprender bastante, mesmo tendo apenas o Class Browser do Squeak como recurso de pesquisa. Mas convenhamos: uma documentação como esta ainda faz falta, principalmente para os aventureiros que, como eu, não fazem parte do core team do Seaside.

Entendendo o exemplo

Não mostrarei nada de muito complexo aqui, até porque eu também estou aprendendo. Mas o exemplo é interessante para conhecermos algumas das características principais do Seaside, que serão explicadas no decorrer deste post.

Diagrama de estados

Você conhece aquele jogo de “adivinhar o número”? Pois então… criaremos aqui algo parecido. Ao lado, você pode conferir uma imagem que ilustra como a aplicação deverá funcionar.

Ao abrir a aplicação, o usuário irá ver uma mensagem, que deverá confirmar para que o jogo comece. Quando o usuário confirma, o sistema gera um número aleatório entre 1 e 10 e mostra um formulário, que o usuário deve preencher com seu palpite. Em seguida, o sistema checa se o palpite do usuário corresponde ao número gerado aleatoriamente: se sim, o sistema mostra uma mensagem parabenizando o usuário; caso contrário, o sistema re-exibe o formulário, mostrando a contagem de “chutes” até o momento, além de uma mensagem com uma dica, para ajudar o usuário a adivinhar o número.

Esse ciclo continua até o usuário acertar. Por fim, o sistema pergunta se o usuário deseja jogar novamente: em caso afirmativo, um novo número é sorteado e o formulário re-exibido; senão, a mensagem de boas vindas é mostrada.

Ainda em relação ao diagrama, perceba que há um quadrado vermelho em torno de algumas atividades. Basicamente, isso quer dizer que a aplicação não deve permitir que o usuário volte (com o botão back do browser) e re-submeta um palpite após já tê-lo acertado. Em outras palavras, eu quero que as atividades dentro do quadrado vermelho representem um workflow, ou transação.

Introdução

O Seaside trabalha com o conceito de componentes. Neste exemplo, criaremos dois componentes para implementar a aplicação proposta. Um será responsável por controlar o fluxo de navegação do usuário pela aplicação, e o outro que receberá o input do usuário através de um formulário. Mas, antes de prosseguirmos, vamos aprender para que servem duas das mais importantes classes do Seaside: WAComponent e WATask.

A classe WAComponent será sua melhor amiga em um projeto Seaside, pois é através da criação de sub-classes de WAComponent que construímos a aplicação, pedaço por pedaço. Toda sub-classe de WAComponent deve implementar o método #renderContentOn:, pois é através deste que definimos como o componente deve ser renderizado no browser do usuário.

A classe WATask, por sua vez, é parecida com a classe WAComponent (de fato, ela a estende), com a diferença que ela não é usada para nada além de definir uma tarefa, ou melhor, a ordem com que outras tarefas e componentes devem ser chamados de modo a cumprir um determinado objetivo. Em poucas palavras: estenda WATask para definir workflows!

Entendendo a interação entre os componentes

Como pôde ser visto no diagrama de atividades mostrado anteriormente, o fluxo começa quando o usuário confirma que deseja jogar, passando o controle para o fomulário. O formulário é então renderizado no browser do usuário para que ele possa enviar um palpite. Em seguida, quando o usuário submete o formulário, o componente chamador (que é o próprio fluxo) recebe o palpite do usuário e o compara com o número gerado no início. Dependendo do resultado dessa comparação, o formulário é exibido novamente ou a mensagem de sucesso é mostrada.

Certo… talvez tenha ficado confusa a parte em que um componente “passa o controle” para outro. Esse é um conceito muito importante em um framework como o Seaside. Para entender essa coisa do “passa o controle”, imagine uma chamada de método comum:

void main(char** args) {
    foo(); // chama o método ("passa o controle")
}
 
void foo() {
    // faz algo aqui
}

Neste exemplo de código C, quando chamamos um método, o fluxo de execução é modificado, fazendo com que o método chamado assuma o controle. Então, quando o método termina, o fluxo retorna ao método chamador.

Simples não? Agora imagine isso funcionando na web. Imagine que o método main do exemplo fosse um componente da nossa aplicação, e que esse componente pudesse passar o controle para outros componentes, assim como a chamada de método no exemplo, só que com a possibilidade de manter essa pilha de execução entre as requisições HTTP! Isso resolveria um monte de problemas, não é?

Felizmente, é assim que o Seaside trabalha. O conceito por trás disso é chamado de Continuation. A imagem a seguir tenta ilustrar o funcionamento disso no contexto do nosso exemplo:

Sequência de requisições

Se desconsiderarmos por um momento o modelo (limitado) de request/response no qual o protocolo HTTP se baseia, a sequência de interações do usuário para com a aplicação se parece com o especificado no diagrama acima. No diagrama, é como se tivéssemos uma pilha de chamadas que não se perde entre as requisições!

O foco deste post não é explicar a teoria por trás desses conceitos todos, portanto, se você tem interesse em saber mais sobre o assunto, use o Google!

Definindo o fluxo da aplicação

Vamos criar o componente responsável por controlar o fluxo de navegação da aplicação. O componente a seguir estende WATask e possui as variávies de instância number e form que servem, respectivamente, para armazenar o número gerado e o formulário usado para receber o input do usuário:

WATask subclass: #GuessingAppComponent
    instanceVariableNames: 'number form'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'GuessingApp'
 
GuessingAppComponent class>>canBeRoot
    ^true
 
"Accessors for instance variables"
 
GuessingAppComponent>>children
    ^ Array with: self form
 
GuessingAppComponent>>initialize
    "Configure initial values"
 
    self number: 10 atRandom;
        form: (GuessNumberForm new)
 
GuessingAppComponent>>go
    "Start application workflow"
 
    self inform: 'Start the game pushing the button below!!'.
    [self initialize;
        [self call: self form.
            self form number < self number
                ifTrue: [self form message: 'Try a higher value']
                ifFalse: [self form message: 'Try a lower value']]
                doWhileFalse: [self form number = self number]]
        doWhileTrue: [self confirm: 'You won the game using ' , self form guesses asString , ' guess(es)!! Play again?']

Todo o código é bem simples de se entender, com exceção do método #go. Veja que o corpo do método não passa de uma transcrição dos diagramas mostrados anteriormente. Atenção especial para a chamada self call:, que é o equivalente ao exemplo de chamada de método, com a diferença que estamos transferindo o controle para que outro componente possa executar no lugar do componente corrente. Perceba também que este método ainda não está pronto, pois, do jeito que está, a aplicação não está preparada para caso o usuário queira re-submeter um palpite após já tê-lo acertado… faremos isso depois!

Recebendo o input do usuário

Abaixo segue o código do componente usado para receber o palpite do usuário. O componente estende WAComonent e tem as variáveis de instância number, message e guesses. Essas variáveis servem, respectivamente, para: guardar o palpite do usuário quando o formulário é submetido; guardar a dica a ser exibida para o usuário (algo do tipo “chute um valor mais alto”, ou “mais baixo”); e guardar o número de vezes que o formulário foi submetido:

WAComponent subclass: #GuessNumberForm
    instanceVariableNames: 'message number guesses'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'GuessingApp'
 
"Accessors for instance variables"
 
GuessNumberForm>>increment
    "Increments the number of guesses"
 
    self guesses: self guesses + 1
 
GuessNumberForm>>initialize
    "Configure initial values"
 
    self number: 1;
        message: 'Try a number between 1 and 10';
        guesses: 0.
 
GuessNumberForm>>renderContentOn: html
    "Render component"
 
    html heading: self message level: 4.
    html heading: 'You did ' , self guesses asString , ' guess(es) until now' level: 5.
    html form
        with: [html textInput value: self number;
                callback: [:value | self increment; number: value asInteger; answer].
            html submitButton value: 'check my guess!!']

Novamente, a simplicidade impera. A única coisa deste código que vale explicar é o método #renderContentOn:, que serve para que possamos definir o que deve ser retornado ao usuário quando o componente precisar ser renderizado. O método recebe um objeto WAHtmlCanvas por parâmetro, responsável por gerar código XHTML automaticamente. Para quem tem conhecimentos em HTML, o código é bem trivial, com exceção do método #callback, onde colocamos algum código para ser executado quando o formulário for submetido. Perceba a chamada a self answer no final da linha, que é responsável por devolver o controle ao componente chamador (o que executou self call: form).

Demarcando uma transação

Se lembra do quadrado vermelho no diagrama de atividades? Então… precisamos dar um jeito de impedir que o usuário volte a dar palpites após ter descoberto o número. Ou seja: precisamos definir uma transação.

Isso é feito utilizando o método #isolate:, conforme pode ser visto abaixo:

GuessingAppComponent>>go
    "Start application workflow"
 
    self inform: 'Start the game pushing the button below!!'.
    [self initialize;
        isolate: [[self call: self form.
            self form number < self number
                ifTrue: [self form message: 'Try a higher value']
                ifFalse: [self form message: 'Try a lower value']]
                doWhileFalse: [self form number = self number]]]
        doWhileTrue: [self confirm: 'You won the game using ' , self form guesses asString , ' guess(es)!! Play again?']

Não tem mais código, não! É só envolver o trecho desejado em um bloco e passá-lo ao método #isolate:!

O resultado

Confira abaixo algumas screenshots da aplicação em funcionamento:

Tela inicial

Lendo o palpite do usuário

Tela de acerto

Back button não permitido após término do jogo

O que há de errado com a última screenshot? Nada… é isso que acontece quando o usuário, após já ter adivinhado o número secreto, volta algumas telas com o botão back do browser e tenta re-submeter um formulário. Não cheguei a pesquisar, mas acredito que esta página seja customizável.

Desafio

Mesmo em uma aplicação simples como a que foi descrita aqui, fica evidente o quanto o Seaside é produtivo e simples (embora eu ainda não saiba usá-lo direito).

Portanto, proponho aos leitores deste blog que pensem no que deve ser feito para se criar uma aplicação igual (com as mesmas funcionalidades) a mostrada aqui (com a sua linguagem e framework preferidos). Tirando um ou outro, imagino que dê para contar nos dedos de uma só mão os frameworks capazes de fazer tanto com tão pouco. Enfim, sintam-se a vontade para expressar suas opiniões a respeito disso.

Conclusão

Não precisei apelar para frameworks externos só para definir o workflow da aplicação;
Não precisei fazer gambiarras para controlar o estado da aplicação (lembrando que a aplicação suporta diversas instâncias do browser acessando a mesma aplicação concorrentemente);
Não precisei fazer gambiarras para tratar o botão back do browser;
Não precisei fazer gambiarras para que o código XHTML gerado fosse válido;
Não precisei ficar reiniciando o servidor web ou fazendo re-deploy o tempo todo;
Não precisei pagar para conseguir um bom ambiente de desenvolvimento, pois o Squeak sozinho faz muito bem o serviço;

É… acho que esses motivos já são o suficiente para que você dê uma olhada no Seaside. Se não for, santo Deus, o que mais você quer?!

6 lições que aprendi sobre desenvolvimento de softwares

Daniel Martins — Sun, 28 Sep 2008 15:30:20 +0000

É natural do ser humano aprender com os seus próprios erros. Quem aqui nunca vivenciou uma situação inusitada na qual mesmo tendo a impressão de que algo está errado, acabamos ignorando e seguindo em frente. E assim continua até que, num belo dia, a bomba explode e você pensa consigo mesmo: “eu sabia!”.

Essas situações, embora aparentam ser ruins em um primeiro momento, são excelentes oportunidades para nos ensinar algumas coisas que provavelmente não aprenderíamos de outra forma. Aliás, talvez seja até mais fácil aprender com nossos próprios erros do que ler sobre isso em algum livro ou artigo. O problema é que nem sempre é fácil saber tirar algo de bom de situações problemáticas.

Por isso, tentarei fazer um gancho entre esse assunto e a área de desenvolvimento de softwares, mostrando algumas das lições em que aprendi errando. Também seria interessante se os leitores que se identificarem com o assunto também compartilhassem algumas lições que aprenderam em períodos turbulentos. Afinal, errar faz bem!

Lição número 1: confie no código e não no documento

Deixe-me contar uma experiência interessante que tive na faculdade. Certa vez, um de nossos professores chegou na aula, colocou no projetor um Diagrama de Classes e um Modelo Entidade-Relacionamento e disse para a sala:

Esse é o modelo de um sistema de locadora. Nesses diagramas vocês tem tudo o que é preciso pra fazer isso funcionar. Não quero nem saber se vocês não gostam do cara que está sentado do seu lado, se acha que ele tem chulé ou mau hálito; eu quero que vocês aí se organizem e me entreguem isso funcionando até o final da aula.

Enfim, todo mundo se levantou e começou a andar de um lado para o outro e, alguns momentos depois, tínhamos nos organizado para dar início a programação. Pois bem… depois de algum tempo programando o que estava nos diagramas, o professor se volta para a sala e diz, em tom de sarcasmo:

Vem cá, vocês não encontraram nada estranho, não?

Praticamente todo mundo da sala havia percebido que alguns relacionamentos estavam faltando, outros sobrando, outros com a multiplicidade incorreta, entre outras coisas. Ninguém só não havia dito nada antes por pensar que o diagrama era indefectível. Se isso aconteceu em um “projeto de mentira” com duas dúzias de pessoas, quem imagina o que pode acontecer em projetos com dezenas e dezenas de pessoas envolvidas?

O fato é que os erros foram colocados lá propositalmente e isso acabou me fazendo perceber que nem sempre um documento representa fielmente um sistema. O que sempre representa fielmente um sistema é o seu código-fonte!

Durante um tempo, trabalhei numa empresa onde praticamente tudo o que precisava ser desenvolvido era entregue aos programadores na forma de textos (para fins de documentação, diziam). Para você perceber a gravidade da situação, se eu implementasse exatamente o que estava escrito nas folhas que recebia, a chance do sistema sequer compilar era altíssima. Além do mais, as especificações normalmente vinham incompletas, o que fazia com que nós tivéssemos de nos preocupar não em simplesmente programar, mas também de tentar driblar possíveis falhas na especificação.

Eu confesso que, naquele tempo, a minha vontade era dar um tiro na minha própria cabeça. Mas hoje, olhando para trás, percebo que isso fez com que eu adquirisse algumas habilidades que não seriam desenvolvidas se as especificações chegassem perfeitas em minhas mãos.

Lição número 2: escreva testes automatizados

Novamente remetendo aos tempos da faculdade, eu não poderia ter escolhido um tema melhor para o meu TCC do que o desenvolvimento de um framework. Me lembro que fui alertado dezenas de vezes pelos professores de que tratava-se de algo inusitado e que eu não teria direito de reclamar caso algo saísse errado. Bem ameaçador, não acha?

Apesar de assumir o desafio sozinho - pois a faculdade não dispunha de um orientador com experiência em design de frameworks - tudo correu bem nas primeiras semanas de desenvolvimento, afinal o código estava bonito e funcionava bem. O que mais eu poderia querer? Entretanto, um sério (e óbvio) problema foi se instalando sem que eu percebesse: a ausência de testes automatizados.

No começo, quando o framework possuía apenas algumas dezenas de classes - era fácil localizar e corrigir os problemas que apareciam. Mas, quanto mais o código crescia, menos controle eu tinha sobre ele. Fazer experimentações no código já não era mais seguro.

Nessa época eu já sabia como escrever testes e tudo mais. O meu grande equívoco foi pensar que, se poupasse o tempo utilizado na escrita dos testes, eu teria mais tempo para entregar aquilo que prometi no começo do ano. Obviamente, eu não poderia estar mais errado.

Escrever testes automatizados (e até mesmo levá-los a outro nível, como acontece com o TDD) é essencial para que as aplicações evoluam de forma consistente. Sem a segurança que tais testes proporcionam, é impossível garantir que o que foi feito hoje continue funcionando amanhã. Não testar o código é comparável a um jogo de tabuleiros, onde, num momento de azar, você acaba caindo numa casa que diz “volte à primeira casa”.

A grande lição que eu tirei disso foi aprender que os testes não servem unicamente para comprovar que tudo está funcionando (pois isso eu já sabia). Eu aprendi que deixar de escrever testes alegando falta de tempo é burrice. Falando nisso, ainda encontramos pessoas que dizem que testes são ruins porque “é mais código para dar manutenção”, ou “escrever testes consome tempo que não temos” ou ainda “mas quem vai testar os testes?”. Não irei responder a essas perguntas, mas posso dizer que são poucas as coisas que fazem tão bem a um software quanto a criação de testes automatizados.

Lição número 3: desenvolva software para o cliente, não para a infraestrutura

Algumas pessoas, ao se iniciar um novo projeto, já tenta desde o início juntar e configurar o framework de injeção de dependências, o framework web, o framework ORM, e por aí vai. A minha pergunta é: pra quê? Confesso que eu mesmo já fiz isso, mas devo dizer que trabalhar dessa forma não faz muito sentido na maioria dos casos.

Voltando aos tempos de faculdade, uma outra coisa que eu gostava era que nós montávamos os sistemas sem pensar em bancos de dados, latência da rede, essas coisas. Nosso banco de dados era nada mais que algumas instâncias de LinkedHashSet! Então, considerando que algumas boas práticas foram usadas e que o sistema esteja funcionando em memória, trocar o mecanismo de persistência (ou lidar com qualquer outra questão de infraestrutura) era fácil.

Por exemplo, em um sistema de locadora, o caso de uso Alugar Filme não fará nada de diferente caso estejamos persistindo os objetos em um banco de dados em vez da memória. Da mesma forma, o caso de uso Reservar Filme (que envia uma mensagem para o usuário informando quando o filme está disponível) não mudará se trocarmos a implementação atual - que executa…

System.out.println("Filme disponível");

…para uma outra que utiliza a API JavaMail para enviar uma mensagem via SMTP. O que importa é que os objetos estão sendo armazenados em algum lugar e que o usuário é notificado de algum jeito quando o filme que ele reservou está disponível. Acredite, isso é o bastante durante boa parte do desenvolvimento de uma aplicação.

Lição número 4: seja preguiçoso

Uma coisa interessante que aprendi foi que nem todo programador preguiçoso é um bom programador, mas todo bom programador é preguiçoso!

Os bons desenvolvedores possuem um faro aguçado que os permite identificar situações nas quais soluções melhores podem ser adotadas de modo a diminuir esforços, tornando o código (e a aplicação de um modo geral) mais conciso e organizado. Alguns chamam tais situações de cheiros (ou smells), termo este que “pegou” após a publicação do livro Refactoring: Improving the Design of Existing Code, de Martin Fowler.

Para identificar tais situações, vamos começar do básico: o que um desenvolvedor de software mais costuma odiar em seu trabalho? Trabalho repetitivo. Se você precisa fazer uma determinada tarefa e tal tarefa exige a repetição de procedimentos que você suspeita serem supérfluos, então faça um favor para si mesmo: deixe sua preguiça trabalhar por você!

Não sei se você é assim, mas eu costumo aprender as coisas mais rapidamente através de exemplos… então, vamos a eles.

Imagine que você tenha sido selecionado para trabalhar no deployment de uma aplicação. Se você já tentou implantar uma aplicação “no braço”, certamente sabe que, se você for fazer o trabalho manualmente, terá de fazer sempre as mesmas coisas, indefinidamente. O deployment de uma aplicação simples poderia ser exemplificada da seguinte forma:

Organizar as classes compiladas em uma estrutura de diretórios específica;
Copiar bibliotecas que devem estar disponíveis a nível de servidor (como drivers JDBC) no diretório de bibliotecas do Container;
Disponibilizar as bibliotecas usadas pela aplicação em um diretório específico;
Mover os descritores e arquivos de configuração aos locais apropriados;
Gerar um WAR ou EAR;
Implantar o WAR ou EAR no Container;
(Re)iniciar o Container (caso este não suporte hot deployment).

Veja que fazer o deployment de uma aplicação não é assim tão complicado, mas perceba que você terá de fazer essas mesmas tarefas sempre que você precisar rodar a aplicação. Trata-se de algo completamente mecânico e chato.

Neste exemplo, você teria duas opções: continuar fazendo isso manualmente até o dia da sua morte, ou criar um script para automatizar essa tarefa para você. O que você prefere?

Cuidado com os extremos!

Uma coisa importante é não levar essa lição ao extremo (como qualquer outra coisa). Querer achar uma solução mais simples para todos os problemas nem sempre é a melhor saída. Já dizia Albert Einstein:

Faça as coisas o mais simples que você puder, porém não se restrinja às mais simples.

Lição número 5: não tente adivinhar o futuro

Um dos meus professores de faculdade nos contou sobre uma experiência que ele havia feito com outra classe. Ele propôs que os alunos, em grupos, implementassem um sistema qualquer, cuja única restrição era, ao se partir para a fase de implementação, o código deveria refletir exatamente o modelo criado no início do processo, e este, por sua vez, não poderia mais ser alterado! Bem no estilo Waterfall mesmo. Loucura, não? Embora a tarefa não parecesse difícil para os alunos em um primeiro momento, nem é preciso dizer o quanto estavam enganados em relação a isso.

Adivinhem o resultado da experiência? Sistemas que pareciam “faltar uma perna”. Quer dizer, todos os sistemas funcionavam, mas não resolviam os problemas que deveriam. O interessante é que todos os projetos acabaram falhando, apesar de a maioria desses alunos terem escolhido desenvolver algo que conheciam bem (por terem experiências profissionais e tudo mais).

Graças às metodologias ágeis, essa coisa de se tentar prever o futuro está perdendo a força. Acho que todo mundo já entendeu que isso não serve de nada, que mudanças são inevitáveis. O melhor a fazer, então, é saber reagir frente a elas.

Lição 6: aprenda que sempre…

… há algo a aprender.

Em tempos de Mega Sena acumulada…

Daniel Martins — Sun, 28 Sep 2008 01:06:11 +0000

Há algum tempo atrás eu acabei me deparando com um desafio bastante interessante proposto por Rodrigo Sol. O desafio em questão pede a criação do menor programa possível — em qualquer linguagem — para gerar um jogo da Mega Sena. Hehe, impressionante o poder de uma loteria acumulada sobre as pessoas!

Seguem as regras do desafio nas palavras do próprio Rodrigo:

Escrever em qualquer linguagem de programação um programa que realize 100.000 sorteios de um numero entre 1 e 60 e mostre na tela os 6 mais freqüentes.

Ganha quem fizer o programa com o menor numero de linhas possíveis, lembrando que a linha considerada é a linha da unidade léxica da linguagem, portanto a seguinte linha em Java seria considerada duas: int i =0; sysout(i);

Como na época eu estava aprendendo Groovy, não podia deixar esta oportunidade passar. E, de fato, não deixei!

Veja, abaixo, uma solução para o “problema” proposto, usando a linguagem Groovy:

def hist = [:], v
100000.times{hist[v = 1 + Math.random() * 60 as int] = !hist[v] ? 1 : hist[v] + 1}
println hist.keySet().toList().sort{-hist[it]}[0..5].join(',')

Será que dá para reduzir ainda mais esse código?

Update: Resolvi tentar resolver o mesmo problema, só que agora usando Smalltalk:

| s |
s := ((OrderedCollection withAll: ((1 to: 100000) collect: [:each | 60 atRandom])) groupBy: [:each | each] having: [:each | true]) asSortedCollection: [:a :b | b size < a size].
1 to: 6 do: [:each | Transcript show: ((s at: each) at: 1); cr]

Debugando aplicações JavaEE no Glassfish v2

Daniel Martins — Tue, 23 Sep 2008 01:51:40 +0000

Este post, na verdade, é uma dica rápida para quem possui aplicações JavaEE rodando em servidores Glassfish e está tendo dificuldades na hora de rastrear a origem de possíveis bugs no código.

Habilitando o modo de debug

Existem duas maneiras de se habilitar o modo de debug no Glassfish: através do painel de administração ou durante a inicialização do domínio.

Para habilitar o modo de debug por padrão, através do painel de administração, basta marcar o campo Debug na tela JVM Settings e clicar em Save:

Habilitando o modo de Debug

Basta reiniciar o domínio para ver que o servidor abre a porta 9009, através da qual podemos conectar um debugger:

asadmin start-domain domain1

Eis um resumo da saída ecoada pelo Glassfish:

Starting Domain domain1, please wait.
Log redirected to .../server.log.
Redirecting output to .../server.log
Listening for transport dt_socket at address: 9009
Application server is listening at address 9009 for debugger to attach using transport dt_socket
...

A outra forma de se habilitar o modo de debug é fornecer o parâmetro --debug ao iniciar o domínio. Por exemplo:

asadmin start-domain --debug domain1

Conectando o debugger da IDE ao servidor

Agora, basta usar os recursos de debugging presentes na sua IDE Java para debugar o código. Por exemplo, se você usa o NetBeans 5.5, basta acessar o menu Run - Attach Debugger… e o configurar da seguinte forma:

Anexando o debugger do NetBeans

O procedimento é semelhante em outras IDEs Java.

Pronto! Feito isso, é só colocar os breakpoints e disparar a execução do código problemático.

JavaEE 5 interceptors

Daniel Martins — Sun, 21 Sep 2008 03:30:58 +0000

É inegável que a não-tão-nova versão 5 da especificação JavaEE veio numa hora mais do que necessária. Todo mundo parecia — e com razão — evitá-la ao máximo, pois seu uso demandava muito tempo e caixas de calmante.

Hoje, criar e manter uma aplicação com EJBs é relativamente simples. E, por este motivo, a adoção da tecnologia passou a ser mais expressiva, mesmo em projetos menores.

Alguns aspectos da especificação, entretanto, ainda deixam a desejar. Um exemplo seria a parte de injeção de dependências, que é limitada apenas a componentes gerenciados pelo container. O que isso quer dizer? Isso quer dizer que, para você poder tirar proveito do esquema de injeção de dependências, todos os seus componentes precisam ser EJBs.

Mas, nesta versão, os EJBs não são POJOs? Sim, mas ter de expor classes simples como EJBs — só para ganhar essa “injetabilidade” de presente — não parece correto. E, da mesma forma, espalhar instanciações de objetos pelos vários componentes da aplicação definitivamente também não parece.

Por isso, mostrarei a seguir um exemplo de como melhorar a parte de injeção de dependências para que possamos injetar POJOs declarativamente em objetos gerenciados. Como o Spring é (de longe) o framework mais conhecido, eu o usarei para me ajudar nesta tarefa.

O exemplo

Para demonstrar o efeito desejado, veja o trecho de código a seguir:

public interface Calculator {
    int mult(int a, int b);
}
 
public class CalculatorImpl implements Calculator {
    public int mult(int a, int b) {
        return a*b;
    }
}
 
@Remote
public interface MultiplicationRuler {
    int[] rulerFor(int number, int from, int to);
}
 
@Stateless
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    public int[] rulerFor(int number, int from, int to) {
        int total = to-from+1;
        int[] ruler = new int[total];
 
        for (int i = 0; i < total; i++) {
            ruler[i] = calculator.mult(number, from++);
        }
        return ruler;
    }
}

O objetivo aqui é implementar um componente POJO que multiplica dois números. Este componente é usado por um segundo — este sim um EJB — que fornece um método que funciona mais ou menos igual aquelas réguas de tabuada; o método recebe o número desejado e dois outros números que representam os limites da tabuada. Por exemplo, a chamada abaixo retorna os resultados da tabuada de 10, começando no número 1 e indo até o 15:

MultiplicationRulerBean ruler = new MultiplicationRulerBean();
ruler.rulerFor(10,1,15);

Note, na classe MultiplicationRulerBean, que o atributo Calculator está anotado com @InjectBean. Esta anotação servirá para indicar que este campo representa uma dependência que deve ser resolvida injetando-se uma instância de Calculator.

Usando o Spring para obter dependências

Segue um exemplo de arquivo de contexto appcontext-services.xml:

 version="1.0" encoding="UTF-8"?>
>
     id="calculatorBean" class="CalculatorImpl" />
>

Como nossa única dependência externa é uma instância de Calculator, então o arquivo se resume a apenas uma entrada . Agora, precisamos criar uma classe que será usada para obter os objetos declarados no arquivo mostrado:

public class SpringBeanContext {
 
    private static final SpringBeanContext instance;
    static {
        instance = new SpringBeanContext();
    }
 
    private ApplicationContext context;
 
    private SpringBeanContext() {
        context = new ClassPathXmlApplicationContext("META-INF/spring/appcontext-*.xml");
    }
 
    public Object getBean(Class clazz) {
        Map,?> beans = context.getBeansOfType(clazz);
        if (beans != null && beans.size() > 0) {
            return beans.values().iterator().next();
        }
        throw new NoSuchBeanDefinitionException("There's no bean of type " + clazz);
    }
 
    public static SpringBeanContext getInstance() {
        return instance; // retorna o singleton
    }
}

Como apenas precisamos de um objeto da classe SpringBeanContext, esta foi programada como sendo um Singleton. Podemos ver que, quando o Singleton é instanciado, os arquivos de contexto — que seguem a convenção appcontext-[modulo].xml — são carregados pelo Spring. O método getBean() foi criado para que possamos obter objetos gerenciados pelo Spring.

Definindo a anotação @InjectBean

Agora, precisamos criar uma anotação que utilizaremos para indicar as dependências de nossos EJBs:

@Retention(RetentionPolicy.RUNTIME)
public @interface InjectBean {}

A anotação @InjectBean, que não possui parâmetros e é visível em Runtime, servirá para indicar os atributos que representam dependências. O interceptor, que definiremos a seguir, irá procurar por essa anotação nos EJBs interceptados. Então, para cada campo anotado com essa anotação, o interceptor irá obter o objeto correspondente do contexto do Spring e injetá-lo.

O Interceptor

Finalmente chegamos à classe que é responsável por fazer o trabalho pesado:

public class SpringBeanInterceptor {
 
    @PostConstruct
    public void injectSpringBean(InvocationContext context) throws Exception {
        Object target = context.getTarget();
        for (Field field : getAnnotatedFields(target.getClass())) {
            injectBean(target, field);
        }
        context.proceed();
    }
 
    protected List<Field> getAnnotatedFields(Class clazz) {
        List<Field> fields = new LinkedList<Field>();
        for (Field field: clazz.getDeclaredFields()) {
            if (field.getAnnotation(InjectBean.class) != null) {
                fields.add(field);
            }
        }
        return fields;
    }
 
    protected void injectBean(Object target, Field field) throws Exception {
        Object bean = null;
        bean = SpringBeanContext.getInstance().getBean(field.getType());
        if (!field.isAccessible()) {
            field.setAccessible(true);
        }
        field.set(target, bean);
    }
}

Nada de outro mundo, não? Perceba que usamos a anotação @PostConstruct, o que indica que o método anotado deve ser executado para um EJB após sua criação pelo container. Todo método interceptador deve retornar void e esperar um parâmetro do tipo InvocationContext. Neste método, utilizamos um pouco de Reflection para injetar o objeto fornecido pelo Spring. Por fim, para que outros possíveis interceptors (e o próprio método sendo interceptado) possam ser invocados, chamamos InvocationContext.proceed().

Para finalizar o exemplo, nos resta associar este interceptor com o EJB da aplicação. Uma forma simples de fazer isso seria através do uso da anotação @Interceptors nas classes e métodos desejados. Por exemplo:

@Stateless
@Interceptors(SpringBeanInterceptor.class)
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    // ...
}

Claro que, para este pequeno exemplo, esta abordagem poderia ser utilizada sem nenhum problema. Porém, definir o interceptor dessa forma é muito trabalhoso em situações onde temos muitos EJBs.

Para que possamos evitar o uso repetido da anotação @Interceptors, podemos fazer a configuração via XML, o que nos permite associar um interceptor a vários EJBs através do uso de curingas. Para isso, basta modificar o arquivo ejb-jar.xml:

 version="1.0" encoding="UTF-8"?>
>
	>
		>
			>Spring-aware interceptor>
			>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor>
		>
	>
 
	>
		>
			>*>
			>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor>
		>
	>
>

Neste caso, estamos associando o interceptor automaticamente a todos os EJBs, nos livrando de ter que configurar manualmente a associação do interceptor com possíveis novos EJBs que a aplicação venha a ter.

Conclusão

Venho observando que frameworks como o Spring e a especificação JavaEE estão trilhando caminhos diretamente opostos; enquando os primeiros estão crescendo descontroladamente e ficando cada vez mais complexos, o segundo está tirando a gordura e ficando mais simples de usar. Claro que cada desenvolvedor tem seus motivos para escolher um ou outro, mas eu particularmente já não vejo tanta vantagem em se adotar o Spring ao EJB. Por outro lado, penso ser mais interessante a junção dessas tecnologias de modo que cada uma contribua com o seu melhor.

Como vimos, a especificação JavaEE 5 — que foi projetada para ser estensível e fácil de usar — conta com componentes denominados interceptors, que nos fornecem um recurso à la AOP, nos permitindo executar código em pontos bem definidos durante a execução da aplicação.

Eu nem preciso dizer que os interceptors podem ser usados para outras coisas além da mostrada aqui. Apenas para citar um exemplo, o framework Seam usa interceptors para implementar o que seus autores chamam de Bijeção — que permite que um componente qualquer possa receber/ejetar dependências de/para um contexto.

Os conceitos apresentados aqui podem ser adaptados para uso com outros frameworks de injeção de dependências, como Guice e PicoContainer.