Java Magazine - Edição 039.pdf

(1)

JavaMail Aplicado

Criando uma mala direta em HTML

com anexos, fazendo personalização

através de expressões regulares

RIA com OpenLaszlo

Crie Rich Internet Applications e traga

interatividade de desktop às suas

aplicações web, com Flash, XML e J

ava

SWT com Visual XP

Torne suas aplicações gráficas mais

integradas ao sistema operacional

Dicas na

We

b

Recapitulando técnicas essenciais

na programação com servlets e JSPs

JGoodies Binding

Ligue componentes gráficos a objetos

de negócio mantendo a abstração OO

Conheça a fundo

todas as novidades,

de motivações a efeitos práticos – com

um tutorial no GlassFish

Explorando a Plataforma

A nova API de persistência do EJB 3.0

que muda as bases do

mapeamento

objeto-relacional em Java

Jav

a Persist

ence API

J

A

V

A

E

5

5 J

J

A

V

A

E

5

A Revista da

Comunidade Java Brasileira

Edição 39 - Ano V - R$ 9,90

jm39.indb

(2)

jm39.indb

(3)

(4)

Conteúdo

D

e

s

k

t

o

p

W

e

b

C

a

p

a

S

e

ç

õ

e

s

J

AAVAVA

EE 5

O

OSVALDOSVALDO P PINALIINALI D DOEDERLEINOEDERLEIN

Explorando a nova versão do Java corporativo: anotações, injeção de Explorando a nova versão do Java corporativo: anotações, injeção de dependên-cias, novas JSRs e um exemplo prático usando o servidor open source GlassFish cias, novas JSRs e um exemplo prático usando o servidor open source GlassFish

16

16 P

P

ERSISTÊNCIAERSISTÊNCIANONO

J

AVAVAA

EE 5

A

ANDRÉNDRÉ D DANTASANTAS R ROCHAOCHAEE S SÉRGIOÉRGIO O OLIVEIRALIVEIRA K KUBOTAUBOTA

Aprenda a utilizar a nova Java Persistence API, de conceitos de mapeamento Aprenda a utilizar a nova Java Persistence API, de conceitos de mapeamento objeto-relacional, a um

objeto-relacional, a um exemplo completo usando Texemplo completo usando Toplink Essentials e MySQLoplink Essentials e MySQL

28

28 R

R

ECAPITULANDOECAPITULANDO

: D

ICASICASNANA

W

EBEB

F

FELIPEELIPE L LEMEEME

Obtendo as versões suportadas de JSP e servlets, usando forward e redirect, Obtendo as versões suportadas de JSP e servlets, usando forward e redirect, manipulando JavaBeans em taglibs e alterando o nome de arquivos para download manipulando JavaBeans em taglibs e alterando o nome de arquivos para download

10

10 C

C

AFEÍNAAFEÍNA

News & Bits

L

LEONARDOEONARDO G GALVÃOALVÃO

Novos produtos wireles

Novos produtos wireless, Ts, TestNG 5, repositório estNG 5, repositório open source open source do Google,do Google, Subversive 1.0

Subversive 1.0

SWT com visual nativo do XP

F

FERNANDOERNANDO L LOZANOOZANO

Faça o Eclipse e outras aplicações SWT assumirem o visual do Windows XP Faça o Eclipse e outras aplicações SWT assumirem o visual do Windows XP

06

06 AJAX A

AJAX A

VANÇADOVANÇADOCOMCOM

GWT

A

ARIRI D DIASIAS N NETOETO

Explore a API

Explore a API do Google Web Toolkit e crie novos componentes,do Google Web Toolkit e crie novos componentes, desenvolvendo aplicações altamente interativas com AJAX e Java desenvolvendo aplicações altamente interativas com AJAX e Java

38

38 U

U

MAMA

M

ALAALA

D

IRETAIRETACOMCOM

J

AAVAVA

M

AILAIL

Y

YARAARA S SENGERENGEREE A ANANA A ABRANTESBRANTES

Utilize a API JavaMail para enviar e-mails em HTML com anexos para múltiplos Utilize a API JavaMail para enviar e-mails em HTML com anexos para múltiplos destinatários, e personalize mensagens usando expressões regulares

destinatários, e personalize mensagens usando expressões regulares

62

62 RIA

RIA

COMCOM

O

PENPEN

L

ASZLOASZLO

A

ANDRÉNDRÉ L LUÍSUÍS M MONTEIROONTEIRO

Turbine suas interfaces gráﬁcas e maximize a interatividade com o usuário Turbine suas interfaces gráﬁcas e maximize a interatividade com o usuário utilizando uma plataforma open source baseada em Flash, XML e Java utilizando uma plataforma open source baseada em Flash, XML e Java

70

70 I

I

NTERFACESNTERFACES

G

RÁFICASRÁFICASCOMCOM

Q

UALIDADEUALIDADE

– P

ARTEARTE

2

H

HUGOUGO V VIDALIDAL T TEIXEIRAEIXEIRA

Descubra como aplicar o pattern Presentation Model e a API Binding do Descubra como aplicar o pattern Presentation Model e a API Binding do

JGoodies para construir GUIs com produtividade, favorecendo os testes unitários JGoodies para construir GUIs com produtividade, favorecendo os testes unitários

50

jm39.indb

(5)

C

om o Java Enterprise Edition 5.0, entramos em numa nova e importante geração do desenvolvimento corporativo. O foco na facilidade de uso, a ab-sorção de técnicas utilizadas em produtos open source, uma participação sem precedentes da comunidade e uma implementação de referência que já rivaliza com os melhores servidores de aplicações... Talvez pela primeira vez na história do Java corporativo vemos lançada uma versão que é sucesso entre as mais diversas castas de desenvolvedores Java. O Java EE 5.0 faz grandes correções de rumo, criando novas tecnologias que tornam obsoletas áreas problemáticas da especificação como os tão polêmicos Entity Beans, incorpora mais do que nunca os web services, e já olha adiante integrando-se com várias novidades que virão no Java SE 6.0 (Mustang). Quem diria que uma especificação do JCP, envolvendo gigantes do mercado com visões e perfis tão distintos como Sun, IBM, Oracle, BEA, Motorola, Cisco e SAP, chegaria a um con-senso de tal solidez, criando uma especificação tão eficaz e alin hada às necessidades do mercado? Mas foi o que aconteceu, em mais uma demonstração da efetividade do Java Community Process e da força da comunidade Java.

Nesta edição, o Java EE 5 é tratado em dois artigos aprofundados. Em uma visão geral da plataforma, você conhece todas as grandes novidades, com diversos exem-plos funcionais, e ainda um tutorial mostrando como criar uma aplicação usando uma seleção dos novos recursos da especificação, além do GlassFish, o servidor que é a base da implementação de referência do novo Java EE. Em um segundo artigo, é vista em detalhes a API que tem chamado mais atenção no Java EE 5, a Java Persis-tence API (JPA). Parte da especificação do EJB 3.0, mas planejada como especificação independente na sua próxima versão, a JPA se inspira fortemente em ferramentas de mapeamento objeto-relacional como Hibernate e iBatis, padronizando uma área fundamental do desenvolvimento corporativo. Você vai conhecer os fundamentos da JPA, e criar um exemplo completo usando vários tipos de associações e herança.

Ainda nesta edição, confira um artigo sobre desenvolvimento AJAX que explora a API do Google Web Toolkit para criar componentes altamente interativos e integrá-los em uma aplicação sofisticada com acesso a dados. Veja também como melhorar suas aplicações desktop usando o pattern Presentation Model e a API JGoodies Bin-ding, que permite vincular os seus modelos OO à interface gráfica de forma eficaz e organizada.

Em outra matéria passo a passo, é mostrado como criar uma mala direta completa usando a API JavaMail e expressões regulares. E mais um artigo voltado à internet mostra como usar o OpenLaszlo para criar Rich Internet Applications, baseadas em Flash, XML e Java. Finalmente, nesta edição retomamos a seção “Recapitulando”, dessa vez trazendo dicas sobre o desenvolvimento com JSP e servlets; também incluímos um artigo especial no Cafeína mostrando como fazer sua aplicação

SWT se integrar perfeitamente ao visual do Windows XP. Boa leitura!

Leonardo Galvão

Diretor de Marketing Gladstone Matos

Diretor Comercial Casseano Filho

Edição

Publisher e Editor-Chefe

Leonardo Galvão (leonardo@javamagazine.com.br )

Editores-Adjuntos

Fernando Lozano (lozano@javamagazine.com.br ) Osvaldo Doederlein (osvaldo@javamagazine.com.br )

Colaboraram nesta edição

Ana Abrantes, André Dantas Rocha, André Luís Monteiro, Ari Dias Neto, Fernando Lozano, Hugo Vidal, Leonardo Galvão, Osvaldo Doederlein, Sérgio Kubota, Yara Senger

Arte

Diretor de ArteTarcísio Bannwart ( phdesign@phdesign.com.br )

DiagramaçãoJaime Peters Junior, Lais Pancote e Tersis Zonato

IlustraçõesFelipe Machado e Francisco Peixoto

CapaFelipe Machado

Produção

Gerência de Marketing Kaline Dolabella

Distribuição

Fernando Chinaglia Distribuidora S.A. Rua Teodoro da Silva, 907, Grajaú - RJ

CEP 20563-900, (21) 3879-7766 - (21) 2577-6362

Atendimento ao leitor

A DevMedia possui uma Central de Atendimento on-line, onde você pode tirar suas dúvidas sobre serviços, enviar críticas e sugestões e falar com um de nossos atendentes.Através da nossa central t ambém é possível alterar dados cadastrais, consultar o status de assinaturas e conferir a data de envio de suas revistas.Acessewww.devmedia.com.br/central, ou se preferir entre em contato conosco através do telefone 21 2283-9012.

Edições anteriores

Adquira as edições anteriores da revista Java Magazine ou de qualquer outra publicação do Grupo DevMedia de forma prática e segura, em

www.devmedia.com.br/anteriores.

Esp

(6)

Edição 39• Java Magazine 5

simples configuração do container web (no caso do Tomcat, a ativação da válvula “SingleSignOn”) faz com que o login em uma aplicação seja automati-camente repassado para todas as outras aplicações dentro do mesmo servidor de aplicações, ou do mesmo cluster de servidores de aplicações.

As dificuldades surgem quando o desenvol-vedor, em vez de adaptar seus programas aos recursos de segurança previstos pelo Java EE, cria sua própria solução “personalizada” de autenticação. Mas não há motivos para se fugir aos recursos padrões do Java EE, pois qualquer servidor de aplicações com um mínimo de qua-lidade é capaz de usar senhas armazenadas em vários locais, como bancos de dados, diretórios LDAP ou mesmo as senhas de rede em Windows, Linux e Netware.

aço do Leitor

Participe!

Envie sua dúvida, comentário, correção ou

sugestão, com nome completo, cidade e estado, para:

cartas@javamagazine.com.br

Cartas publicadas podem ser editadas por motivos de clareza ou extensão.

SOA

Sou assinante da Java Magazine e gostaria primeiramente de parabenizá-los pela excelente qualidade do material apresentado. Também gostaria de saber de vocês se há possibilidade de publicar na revista um artigo falando sobre SOA e web services, visto que o assunto é cada vez mais comentado na comunidade Java.

Michel Pires da Silva Web Services e SOA (Service-Oriented Archi-tecture) foi um dos assuntos de capa da Java Magazine 34. O artigo de Osvaldo Doederlein cobriu desde as tecnologias precursoras dos web services como RPC, até o atual enfoque na criação de arquiteturas orientadas a serviços.

Java EE 5

Gostaria de ver as novidades do Java EE 5 nas próximas edições. Afinal de contas, a especificação já foi aprovada , e a Java Magazine sempre nos

apresenta as novidades em primeira mão. Michel Zanini Esta edição atende ao seu pedido! Além de um artigo fornecendo uma visão geral da nova plataforma destacando as prin cipais mudanças, você verá uma matéria sobre uma das mais

importantes novidades do Java EE 5: a Java Persistence API.

Ferramentas

Parabenizo a Java Magazine pelas excelentes edições. Sou iniciante em Java e uma das grandes dificuldades para um iniciante é, além de aprender a linguagem, saber utilizar as ferramentas exis-tentes. E a Java Magazine sabe nos mostrar como utilizar essas ferramentas de forma muito didática, o que facilita bastante a vida dos iniciantes.

Rubens Renato Lima

Autenticação integrada no Java EE

Tenho várias aplicações Java EE e preciso que elas trabalhem com um único login. Ou seja, quando o usuário efetuar o login em uma das aplicações, será necessário que todas as outras trabalhem com essa autenticação. Existe alguma forma de compartilhar as informações de autenticação entre as aplicações?

Everton Trindade Os dois artigos “Segurança no J2EE”, publicados nas Edições 22 e 23 respondem em detalhes à sua pergunta. De forma resumida, se sua aplicação utili-za os recursos de autenticação e controle de acesso

baseados emroles definidos pelo Java EE, uma

E

stou desenvolvendo uma aplicação Swing usando NetBeans 5 e JDK 1.5, a qual solicita login e senha. Ela deveria bloquear todas as janelas da área de trabalho, só liberando-as após a autenti-cação. Mas não consigo descobrir como configurar um diálogo modal para a área de trabalho como um todo, como seria possível usando Delphi ou Visual Basic.

Eloir Cortes Infelizmente nem o Swing nem o AWT forne-cem o recurso conhecido como “system modal” no Windows, que permite bloquear todas as aplicações na área de trabalho até que o diálogo seja fechado. Até o Java SE 5.0, é possível criar

diálogos modais apenas com respeito à própria aplicação que o criou. No Java 6 (Mustang), haverá um controle mais fino sobre diálogos modais, mas ainda assim o máximo será restringir

todas as aplicações Java na área de trabalho, não

afetando as aplicações nativas. Veja mais sobre as mudanças em diálogos modais no Java 6 em java.s un.com /develo per/te chnical Artic les/J2SE/

Desktop/mustang/modality .

É possível, pelo menos no Windows, configurar diálogos Swing como “system modal” mas isto envolve o uso da tecnologia JNI (Java Native Interface) para chamar funções da API nativa do Windows (Win32 API). Lembrando que uma aplicação usando este recurso, é claro, não seria

portável. O site para desenvolvedores da Borland tem um bom artigo explicando como fazer isso: community.borland.com/article/0,1410,20679,00. html .

Por outro lado, aplicações SWT têm o recurso de “system mo-dal” disponível: b a s t a c o n f i -g u r a r o e s t i l o SWT.SYSTEM_MODAL na criação de um Dialog ou de umShell.

Diálogos modais para a área de trabalho

(7)

6 Java Magazine•Edição 39

Cafeín

News & Bits

O

Carbide.j é um conjunto de ferramentas integradas voltado à criação, depuração e testes de aplicações Java para dis-positivos Nokia, que pode ser executado independentemente ou de forma integrada a um IDE (são suportados o Eclipse 3.0 e 3.1, JBuilder Mobile Edition, NetBeans 4.x e 5.0, e IBM WebSphere Studio Device Developer 5.6 e 5.7). Com o Carbide.j, você pode criar aplicações baseadas nos perfis MIDP e Personal Profile, assi-nar pacotes de aplicações MIDP, configurar e gerenciar SDKs da

Nokia (há um SDK da empresa para cada série de dispositivos), e realizar a instalação/deployment usando conexões RS232 (serial), IrDA (infra-vermelho) e Bluetooth, assim como FTP. Há ainda um designer de interfaces gráficas com suporte a dez tamanhos de telas, entre outras funcionalidades.

A novidade mais importante da versão 1.5 é o suporte ao cha-mado “on-device debugging”, que permite realizar a depuração de aplicações em execução no próprio dispositivo. Há também suporte a novos dispositivos e várias melhorias, especialmente na integração com o Eclipse e no designer de interfaces.forum.nokia.

com/main/resources/tools_and_sdks/carbide.

A

plataforma Scalable Network Application Package (SNAP) da Nokia suporta a criação de jogos móveis conectados e comunidades de jogadores, através de uma API cliente e uma infra-estrutura de serviços. Para comunidades, são oferecidos recursos para conversas on-line e criação de listas de amigos, indicadores de presença (on-line, off(on-line, jogando) e rankings, para estimular a competição. Há funcionalidades para jogos “ponto a ponto”, nos quais dois adversários jogam um contra o outro do começo ao fim,

e também a possibilidade de pesquisar e escolher adversários e montar salas virtuais. Outro ponto forte são os recursos para a criação de sites com notícias e eventos, quadros de mensagens moderados e páginas de apresentação dos jogos. A plataforma SNAP roda sobre o MIDP 2.0 e é baseada na plataforma Arena criada para o N-Gage (os primeiros ce-lulares da Nokia com suporte especial a jogos), que já conta com mais de 500 mil usuários cadastrados. Um atestado da importância do SNAP é a sua inclu-são no novo Wireless Toolkit 2.5 da Sun.

snapmobile.nokia.com.

Nokia Carbide.j 1.5

SNAP Mobile SDK 1.2

(8)

TestNG 5.0

O framework de testes TestNG é o principal concorrente do JUnit, e se posiciona como uma alternativa mais capaz e mais moderna (NG é uma abreviação de “New Generation”). Primeiro framework de testes a suportar anotações (mesmo antes do Java 5), o Tes-tNG inclui suporte a métodos dependentes e parâmetros, distribuição de testes e testes orientados a dados.

O TestNG segue um modelo de execução que

dispensa o uso do tradicionalTestSuite e traz

o BeanShell embutido. Há também plug-ins para várias ferramentas, entre elas o Eclipse e o Apache Maven. A versão 5.0 tem melhorias importantes nos relatórios de testes gerados, com uma estrutura mais organizada e mudan-ças visuais. Outro destaque é o trabalho com

stack traces, que agora podem ser mostrados

interativamente nos relatórios HTML, sendo

possível também filtrá-los.testng.org

Subversive 1.0.0

Um dos mais populares plug-ins Eclipse para integração com o sistema de controle de versões Subversion, o Subversive chegou à versão 1.0.0. O Subversion é considerado em muitos pontos melhor e mais moderno que o CVS e hoje é adotado como sistema de controle de versões oficial da Fundação Apache, entre outras organizações. O objetivo do plug-in Subversive é trazer para o Eclipse o mesmo

nível de suporte oferecido no IDE para o CVS. polari on.org.

LimpidLog

A nova API de logging open source LimpidLog tem uma proposta radical, que pode simplificar o log de informações sobre classes durante a execução. Em vez de codificar chamadas à API de logging, você registra a classe a ser monitorada e o LimpidLog acom-panha e loga informações importantes sobre o que está sendo feito na classe (isso vale para mensagens do tipo TRACE e ERROR; para outros casos, ainda será necessário chamar uma API de logging comum). A API usa a classe java. lang.ins trume nt.In strumenta tion para instru-mentar classes e é capaz de logar eventos de chamada/entrada/saída de métodos, atribui-ção de variáveis e levantamento de exceções. acelet.com/limpidlog.

Jahia Community Edition

Mais um produto importante liberado como open source, o Jahia Community Edition torna disponível sob uma licença CDDL modificada, 80% do código do produto. São mais de 2.200 classes e arquivos.

O Jahia é uma “plataforma web unificada”, que integra tecnologias como ECM ( Enterprise Content Management) e portlets, bem como um gerenciador de documentos baseado no Apache Slide e um mecanismo de buscas

construído sobre o Apache Lucene. Recursos enterprise não disponíveis na versão Commu-nity, como Single Sign-On e suporte a clusters estão acessíveis sob uma licença baseada na idéia de “contribuição ou pagamento”, pela qual empresas ou indivíduos podem escolher pagar royalties pelos recursos adicionais, ou trocá-los por contribuições para o projeto. jahia.o rg.

Google lança repositório open source

O Google lançou um novo repositório de projetos open source, baseado no sistema de controle de versões Subversion, e subordinado ao portal “Google Code” (que hospeda projetos como a Go ogle Search API). O cadastro de novos projetos é simples e há recursos completos de busca, além de navegação por palavras-chave. Para registrar um projeto, é necessário ter uma conta no Google, o que abre a possibilidade de se usar diversos ou-tros serviços da empresa juntamente com o repositório.

Um detalhe interessante é que apenas algu-mas licenças open source são acei tas. Diz o FAQ do Google, “A comunidade open source está cheia de licenças praticamente iguais. Gostarí-amos que projetos fossem padronizados com as licenças mais populares e maduras”. O

repo-sitório inclui ainda recursos deissue tracking,

em um módulo que foi criado inteiramente

pelo Google.code.google.com/hosting.

a

L

EONARDO

G

ALVÃO

(9)

com visual

SWT

nativo do XP

com visual

SWT

nativo do XP

Figura 2. ExemploEnderecoTerrestre.java com a aparência nativa do Windows XP.

Figura 1. ExemploEnderecoTerrestre.java como exibido na instalação padrão do SWT no Windows XP, assumindo a aparência padrão do Windows 98 e 2000.

manifest à instalação padrão do JRE ou JDK. Assim sendo, o arquivo deve ser instalado manualmente pelos próprios usuários.

Do lado da Microsoft, este arquivo tem sua razão de ser, pois ele permite que apli-cações criadas para versões anteriores do Windows executem sem modificações no XP. Ao mesmo tempo, ele torna fácil para os desenvolvedores adequarem suas aplicações ao novo visual, sem esforço adicional de programação.

Em versões anteriores do Windows, a Microsoft simplesmente forçava todas as aplicações a assumirem o novo visual (por exemplo, do Windows 3.1 para o Windows 95). Entretanto, isto criava problemas quando a aplicação utilizava componentes customi-zados que não se adequavam bem ao novo visual. Por isso, no XP, qualquer aplicação pode ser configurada para o visual “antigo” ou para o novo.

executável javaw.exe utilizado para rodar as aplicações SWT em seu computador.

Os programas javaw.exe e java.exe são ambos alternativas para a execução de uma máquina virtual Java (JVM). A única diferença entre eles é que o cabeçalho do javaw.exe diz ao Windows que ele é uma aplicação gráfica, e assim sua execução não provoca a abertura de uma janela de console ou prompt do MS-DOS.

Uma vez criado (ou copiado) o arquivo, a linha de comando a seguir executa o exemplo conforme visto naFigura 2:

javaw EnderecoTerrestre

A criação do arquivo irá afetar todas as apli -cações SWT executadas neste computador, inclusive o próprio Eclipse. AsFiguras 3 e 4

mostram o próprio Eclipse antes e depois da criação do javaw.exe.manifest .

Fica a pergunta: por que essa “mágica” não é parte da instalação padrão do Eclipse para Windows? Afinal o arquivo javaw.exe. manifest seria simplesmente ignorado em versões mais antigas do Windows, e assim não causaria prejuízo algum.

A impossibilidade de o arquivo ser instalado pelo próprio Eclipse decorre da licença do Java. A redistribuição do Java da Sun deve ser feita de modo inalterado, assim não é possível para o Eclipse (ou para qualquer outro forne-cedor que não tenha adquirido uma licença especial junto à Sun) acrescentar o javaw.exe.

M

uito se fala que uma das grandes vantagens do SWT sobre o Swing é a aderência ao visual nativo da plataforma, obtido graças ao uso dos com-ponentes gráficos nativos. Entretanto, desen-volvedores de aplicações SWT e usuários do Eclipse em geral devem ter percebido que, no Windows XP, é assumido o visual nativo do Windows 98 e 2000, em vez do visual mais moderno do Windows XP.

Veja naFigura 1, por exemplo, o exemplo

EnderecoTerrestre.java publicado original-mente no artigo da Edição 31 sobre desen-volvimento SWT. A Figura 2 ilustra como deveria ser a aparência da aplicação com o visual nativo do XP.

A boa notícia é que as duas figuras foram geradas pela mesma aplicação. Não foi ne-cessário modificar uma única linha do código Java, nem recompilar a aplicação contra uma versão diferente do SWT.

A solução exige que o arquivo javaw.exe. manifest , apresentado na Listagem 1, seja copiado para a mesma pasta que contém o

FERNANDO LOZANO

com visual

SWT

nativo do XP

(10)

Figura 4. Eclipse depois de criado o arquivo javaw.exe.manifest

Figura 3. Eclipse com sua aparência padrão no Windows XP

Listagem 1. rqu vo javaw.exe.manifest que l xml vers on= . encod ng

assem ly xmlns= urn:sc emas assem lyIdent ty vers on= processorArchitecture=”X name= . avaw type=”win32”/> <description>Standard Widg <dependency> <dependentAssembly> <assemblyIde ntity type name=”Microsoft.Wind vers on= . . . processorArchitectur publicKeyToken=”6595 language=”*”/> </dependentAssembly> </dependency> </assembly>

(11)

Listagem 1.versoes.jsp , obtendo a versão das APIs web suportadas <%@ page import=”javax.servlet.ServletContext” %> <%@ page import=”javax.servlet.jsp.JspFactory” %> <%

ServletContex t sc = pageContext .getServletCo ntext(); String servidor = sc.getServerInfo();

String versaoServlet = “” + sc.getMajorVersion() + “.” + sc.getMinorVe rsion();

String versaoJsp = JspFactory.g etDefaultFact ory(). getEngineInfo().getSpecificationVersion(); %>

<b>Servidor:</b> <i><%= servidor %></i><br> <b>Servlet:</b> <i><%= versaoServlet %></i><br> <b>JSP:</b> <i><%= versaoJsp %></i><br>

Recapi

na

Nesta edição,

recapitulamos um dos

assuntos mais populares

na Java Magazine: o

desenvolvimento com JSP e

servlets. Foram selecionadas

quatro dicas, ainda

totalmente atuais, do artigo

“Dicas na Web” publicado

na Edição 12, que resolvem

dúvidas comuns e exploram

detalhes importantes da

programação web com Java.

N

este artigo são apresentadas dicas úteis sobre JSP e servlets, soluções para problemas recorrentes no de-senvolvimento web, e esclarecimentos sobre alguns procedimentos comuns.

Obtendo as versões de JSP

e Servlets

As tecnologias JSP e servlets evoluíram muito desde suas primeiras versões. Por exemplo, a API de servlets 2.3 introduziu o conceito de filtros (interface

java x.sevle t.Fi lter), e com o JSP 2.0, veio o suporte a uso da Ex-pression Language dentro das páginas.

Para garantir a compatibilidade de suas aplicações web, portanto, é sempre impor-tante saber as versões das APIs suportadas nos containers web utilizados. Os métodos

getMajorVersion()egetMinorVersion() da classe

javax.servlet.ServletContext permitem obter a versão da API de servlets. E sta classe fornece ainda o métodogetServerInfo(), que descreve o nome do servidor e sua versão.

Já para a versão da especificação JSP, é pre-ciso obter um objeto javax.servlet.jsp.JspEnginee chamar seu método getSpecificationVersion(). A

Listagem 1contém uma página JSP que pode

ser usada para obter essas informações.

Definindo o nome do

arquivo em downloads

Um uso comum para servlets (e mesmo para páginas JSP) é a geração dinâmica de arquivos, tais como planilhas ou documentos PDF. Nessas situações, ao enviar o arquivo gerado, é preciso que o servlet especifique o tipo do conteúdo através do método

response.setContentType(String tipo). O tipo segue no cabeçalho da resposta HTTP retornada pelo servlet e, de acordo com ele, o navegador po-derá decidir o que fazer com o arquivo.

Normalmente o arquivo é exibido através de um plug-in, ou é oferecida a opção de salvá-lo no disco, mas nos casos onde a

in-Dicas

Web

(12)

tenção é que o usuário faça o download, esse procedimento traz alguns problemas:

• Não é garantido que o usuário tenha a

opção de salvar o arquivo em vez de o nave-gador abrir automaticamente um plug-in.

•Mesmo que o navegador web ofereça a

opção de salvamento, o nome sugerido será o do servlet ou o da página JSP (por exemplo, “contador.jsp”), sendo que o ideal seria um nome mais amigável, ou ao menos com a extensão correta (como "contador-10.txt").

Para resolver esses problemas, a solução é definir a propriedadecontent-dispositiondo cabeçalho da resposta HTTP, com o valor

attachment;filename= nome.extensão, como no trecho de código a seguir:

response.setHeader( “content-disposition”,

“attachment;filename=” + nomeArquivo );

AListagem 2 inclui uma página JSP que

imprime um contador, de 1 até 10 (ou até o valor definido no parâmetrolimite). Note que o navegador não exibe o conteúdo da página; em vez disso abre a janela com a op -ção de salvar o arquivo, com nome sugerido “contador- XX .txt” (sendo XXo limite).

A propriedadecontent-dispositioné definida no protocolo HTTP (RFC 21831_{), e não na}

API de servlets/JSP. Assim o funcionamento dessa dica depende da compatibilidade do navegador com os padrões W3C, e pode não funcionar em navegadores mais antigos (nesses casos, o nome sugerido continuará sendo o nome do JSP).

Outra opção é definir no descritor

web.xml um mapeamento com o nome

de-sejado (como “relatorio.pdf” ou “contador. txt”) para o servlet ou página JSP responsável pela geração do arquivo, o que funcionará independente do navegador utilizado. No entanto essa solução não tem a flexibilidade de permitir a definição do nome no momento de execução do ser vlet/JSP.

Forward ou redirect?

Uma necessidade muito comum na pro-gramação web é passar o fluxo de execução

para outra página. Existem duas formas de s e fazer isso –forward (encadeamento) eredirect

(redirecionamento). Embora o resultado final pareça muitas vezes ser o mesmo, o funciona-mento é bem diferente sob o ponto de vista do navegador web.

Forward

A primeira forma usa o métodoforward()

da classeRequestDispatcher, como mostra o código daListagem 3.

1_RFCs_{(Requests for Comments)}_{são documentos que}

definem protocolos, modelos ou especificações para os sistemas da internet. De forma ampla, representam para a internet o que os JSRs(Java Specification Requests) são para Java.

Listagem 2.contador.jsp, exemplo simples para demonstrar mudança de nome do download <%

int limite = 10; // valor padrão try {

limite = Integer.pars eInt(request .getParameter (“limite”)); }

catch(Exception exc) {

// ignora exceção (limite=10) }

String nomeArquivo = “contador-” + limite + “.txt”; response.setContentType(“text/plain”);

response.setHeader(“content-disposition”, “attachment;filename=” + nomeArquivo); for (int i=1; i<=limite; i++) {

out.println(i); }

%>

Listagem 3.Forwards em JSPs e servlets Em páginas JSP: RequestDispatcher dispatcher = pageContext.getServletContext().getRequestDispatcher(“/novaPagina.jsp”); dispatcher.forward(request, response); Em servlets: RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(“/novaPagina.jsp”); dispatcher.forward(request, response);

Figura 1. Uso deRequestDispatcher.forward() numa arquitetura simplificada

tulando

F

ELIPE

L

EME

(13)

O métodoforward()repassa a requisição para outro recurso – como um ser vlet, página JSP ou página HTML – dentro do mesmo con-tainer web. Esse recurso pode fornecer uma resposta final ao cliente, ou então repassar novamente a requisição (veja a Figura 1).

Usarforward() é útil quando o primeiro servlet precisa fazer algum pré-processamento (por exemplo, validar se o usuário atual tem permissões para acessar a URL especificada), antes de passar a requisição para o servlet ou JSP que realizará o processamento final. Em particular, é dessa forma que o Struts e outras implementações da arquitetura MVC realizam o trabalho docontroller(veja aFigura 2).

Redirect

A segunda forma de passar o fluxo de exe-cução para outra página consiste em usar o métodosendRedirect() da classeHttpResponse, enviando com isso um comando HTTP SEND REDIRECTpara o navegador web. Nesse caso a requisição volta para o navegador, que automaticamente faz a requisição da página especificada (que não precisa estar localiza-da no mesmo servidor). AFigura 3 ilustra o procedimento.

Comparando as técnicas

ATabela 1 mostra as demais diferenças

entre cada opção, e a Listagem 4 contém uma página JSP com exemplos das duas técnicas. Note que, em ambos os casos, se o buffer de resposta já tiver recebido alguma saída, a tentativa de mudar o f luxo de execução lança umaIllegalStateException. Assim, é recomendável que chamadas a

forward() ou a sendRedirect() sejam feitas no começo do código principal do servlet (doPost(), doGet() etc.), antes de qualquer

chamada aout.print() ou out.println(), como mostrado nos exemplos.

Cuidados com <jsp:useBean>

e <jsp:setProperty>

Uma prática muito comum no desenvol-vimento de páginas JSP é o uso das tags

<jsp:useBean>e<jsp:setProperty> para, respec-tivamente, instanciar JavaBeans e preencher suas propriedades com os valores fornecidos no formulário da página. Embora a prática seja correta, é preciso tomar alguns cuidados com o uso dessas duas tags:

1. O corpo da tag <jsp:useBean>só é exe-cutado quando o JavaBean é instanciado. Assim, se o escopo do bean for de sessão, o código de inicialização só será executado uma vez. Códigos como o seguinte são causa constante de bugs:

<jsp:useBean id=”beanEntrada” scope= ”session” class=”jm.dicas.EntradaDadosBean” scope=”session”>

<jsp:setProperty name=”beanEntrada” property=”*”/> </jsp:useBean>

O problema aqui é que os valores do formulário só são repassados para o bean na primeira vez

Listagem 4.mudaFluxo.jsp, exemplos de encadeamento e redirecionamento Teste de forward e sendRedirect<br><br>

<a href=”mudaFluxo.jsp?tipo=forward&flush=false”> forward válido</a><br> <a href=”mudaFluxo.jsp?tipo=forward&flush=true”> forward inválido</a ><br> <a href=”mudaFluxo.jsp?tipo=sendRedirect&flush=false”> sendRedirect válido</a><br > <a href=”mudaFluxo.jsp?tipo=sendRedirect&flush=true”> sendRedirect inválido</a>< br> <br><br> <% if (“true”.equals(request.getParameter(“flush”))) { out.println(“ <br>Chamando out.flush()< br>”); out.flush();

}

String tipo = request.getParameter(“tipo”); if (tipo != null) {

request.setAttribute(“atributo”, “teste”); try {

if (tipo.equals(“forward”)) { RequestDispa tcher dispatcher =

pageContext.getServletContext(). getRequestDispatcher(“/novaPagina.jsp”); dispatcher.forward(request, response); } if (tipo.equals (“sendRedire ct”)) { response.sendRedirect(“/jm12/novaPagina.jsp”); } } catch(Throwa ble t) { out.println(“Exceção: “ + t.getMessage() + “<br>”); } } %>

Figura 2. Uso deRequestDispatcher.forward() na arquitetura MVC

RequestDispatcher.forward() Response.sendRedirect()

Fl ux o d e e xe cu çã o p er ma ne ce no s er vi do r Fl uxo v ol ta ao cl ie nt e Atributos definidos no request são acessíveis na

nova página

O request da nova página não tem nenhum atribu-to definido

Nova página deve obrigatoriamente estar no mesmo contexto web

Não há restrições quanto à localização da nova página

A URL exibida no navegador continua sendo a da

página que originou a chamada de forward() A URL no navegador muda para a da nova página

A URL da nova página deve começar com “/” Endereço da nova página pode ser qualquer URL

válida

Tabela 1. Diferenças entre redirecionamento e encadeamento

(14)

(15)

que o formulário é submetido. Nas submissões seguintes, o bean já está presente na sessão e não precisa mais ser instanciado; conseqüente-mente a tag<jsp:setProperty>não é executada.

A solução para o problema é retirar a tag

<jsp:setProperty> do corpo de<jsp:useBean>:

<jsp:useBean id=”beanEntrada” class=”jm.dicas.EntradaDadosBean” scope=”session”/>

<jsp:setProperty name=”beanEntrada” property=”*”/>

Ou então mudar o escopo do bean:

<jsp:useBean id=”beanEntrada” class=”jm.dicas.EntradaDadosBean”

scope=”request” >

Os exemplos nasListagens 5 e6 demons-tram o uso correto e incorreto dessas tags (e aListagem 7 inclui o bean simples utilizado por estas).

2.A especificação JSP diz que quando um parâmetro da requisição é nulo ou vazio, a respectiva propriedade não é “setada” através da tag <jsp:setProperty>. É muito comum, porém, o desenvolvedor criar có-digo supondo que essa propriedade será definida com o valor nulo (ou vazio), o que mais uma vez causa bugs quando o bean está armazenado em escopo de sessão. A

Figura 4 ilustra o comportamento da tag

<jsp:setProperty>, passo a passo, sobre o código daListagem 6.

3. O tipo do bean a ser usado por<jsp:useBean>

pode ser definido através dos atributostype e

class. Embora os significados desses atributos sejam semelhantes, eles representam concei-tos ligeiramente diferentes:class define a classe sendo instanciada, enquanto quetype define o tipo do bean, que, além da classe do bean, pode ser uma das suas superclasses ou uma interface implementada por ele. Por exemplo, o código abaixo:

<jsp:useBean id=”meuBean” scope= ”session” type=”java.lang.Object” class=”java.util.Date”/>

seria equivalente a2_:

Object meuBean = (Object) pageContext.getAttribute( “meuBean”, PageContext .SESSION );

if (meuBean == null) {

meuBean =new java.util.Date();

pageContext. setAttribute(“meuBean”, meuBean, PageContext.SESSION_SCOPE);

}

Ou seja, o código gerado tenta recuperar um bean existente no escopo de sessão e associá-lo a uma variável da classe Object

(definida no atributotype). Caso o bean não exista no escopo, uma nova instância da clas-seDate (definida no atributoclass) é gerada e atribuída à variávelmeuBean.

Quando apenastype é usado, o bean precisa obrigatoriamente estar disponível no escopo, senão é lançada uma exceção. Por exemplo, o seguinte trecho de código:

<jsp:useBean id=”meuBean” scope= ”session” type=”java.lang.Object”/>

seria equivalente a:

Object meuBean = ( Object) pageContext.getAttribute( “meuBean”, PageContext .SESSION );

if (meuBean == null) {

throw new InstantiationException( “bean meuBean not found within scope”); }

Listagem 5.usoCorreto.jsp, uso correto das tags<jsp:useBean> e<jsp:setProperty> Exemplo do uso correto das tags:<br>

<jsp:useBean id=”beanEntrada”

class=”jm.dicas.EntradaDadosBean” scope=”session”/> <jsp:setProperty name=”beanEntrada” property=”*”/> <form>

Nome: <input type=”text” name=”nome” value=”<jsp:getProperty

name=”beanEntrada” property=”nome”/>”><br> Email: <input type=”text” name=”email ”

value=”<jsp:getProperty

name=”beanEntrada” property=”email”/>”><br><br> <input type=”submit” value=”Enviar”>

</form>

Listagem 6.usoIncorreto.jsp, uso incorreto das tags<jsp:useBean> e<jsp:setProperty> Exemplo do uso incorreto das tags

(valores dos textfields nunca mudam):<br> <jsp:useBean id=”beanEntrada”

class=”jm.dicas.EntradaDadosBean” scope=”session”>

<form>

Nome: <input type=”text” name=”nome”

value=”<jsp:getProperty name=”beanEntrada” property=”nome”/>”><br>

Email: <input type=”text” name=”email”

value=”<jsp:getProperty name=”beanEntrada” property=”email”/>”><br><br>

</form>

Listagem 7.EntradaDadosBean.java, JavaBean utilizado nas Listagens 5 e 6 package jm.dicas;

public class EntradaDadosBean { private String nome;

private String email; //... métodos get/set }

Figura 3. Redirecionamento comResponse.sendRedirect()

2_{O código mostrado aqui é parecido com o gerado pelo}

compilador JSP, porém simpliﬁcado: além do tratamento de exceções ter sido omitido, os objetos foram instancia-dos através do operadornew, enquanto que o compilador JSP usa java.beans.Beans.instantiate().

(16)

Figura 4. Exemplo de uso incorreto do tag<jsp:setProperty>

Assim que a página é acessada, o bean é instanciado, porém nenhu-ma propriedade é setada (já que não foram passados parâmetros à requisição).

Após serem preenchidos os valore s do nome e e-mail, o formulário é submetido. No servidor, o bean já existe na sessão e não é instanciado novamente. Porém, como os valores dos parâmetrosnome eemail são não-nulos, as respectivas propriedades do bean são setadas.

O formulário é submetido co m um novo nome, mas sem o endereço de e-mail fornecido, então apenas a p roprieda denome será setada no bean que está na sessão.

Resultado final: o nome foi alterado, mas o e-mail não.

Usar a variação de <jsp:useBean> apenas comtype é muito útil em alguns casos; por exemplo, quando um objeto representan-do um usuário é criarepresentan-do apenas na página de login e precisa ser acessado em outras páginas. Mas é preciso se ter em mente que o tag pode causar uma exceção (se a sessão expirar, digamos), e dessa forma ter os devi-dos cuidadevi-dos. Uma saída seria o uso de tags JSTL para checar a existência do objeto na sessão, como no código seguinte:

<c:if test=” ${empty sessionScope.beanEntrada}”> <c:redirect url=”sessaoExpirada.jsp”/> </c:if>

<jsp:useBean id=”beanEntrada” scope= ”session” type=”jm.dicas.EntradaDadosBean”/>

Felipe Leme

(felipeal@gmail.com) é

Engenheiro de Computacão pela UNICAMP, membro atuante das comunidades Java brasileira e mundial, tendo publicado artigos em revistas técnicas e sites internacionais e palestrado nas principais conferências sobre Java, além de participar como expert no JCP e ser committer em projetos da Apache. Atualmente é Diretor Técnico da Voxblue (voxblue.com)

e instrutor da Globalcode.

(17)

Um

Enterprise Edition

muito mais fácil

Java EE 5

(18)

Explorando a nova versão do

Java corporativo: anotações,

injeção de dependências,

novas JSRs e um exemplo

prático no servidor open

source GlassFish

O

SVALDO

P

INALI

D

OEDERLEIN

A

o reler meu primeiro artigo na Java Mag az ine, “J2 EE Fu nda-mental” (Edição 1, julho de 2002), abordando o então recém-lançado J2EE 1.3, pude verificar como o status da plataforma mudou. Eram apresentados fundamentos como containers, servidores de aplicações e EJB, até então pouco familiares para muitos desenvolvedores. Servidores J2EE eram ferramentas caras e pesadas, e a portabilidade ainda deixava a desejar para os padrões do Java. Alguns componentes, como os Entity Beans, estavam francamen-te imaturos – isso quando não já tinham sido descartados por muitos. O artigo ter-minava com uma seção “Web services: o futuro”, já anunciando o J2EE 1.4 (lançado em novembro de 2003), mas apontando os problemas de compatibilidade de padrões ainda em definição. Hoje em dia, poderí-amos reclamar que já existem padrões de Web Services até em demasia.

Passados quatro anos, a plataforma, agora rebatizada Java EE, dispensa apre-sentações, tendo se constituído num com-ponente obrigatório do conhecimento de qualquer desenvolvedor Java atuando no “lado do servidor” (server-side). Mesmo

frameworks que correm por fora e ga-nharam prestígio e popularidade, como Spring e Hibernate, têm ocupado um lugar mais complementar do que alternativo em relação ao Java EE. E numa exibição surpreendente de resposta às direções escolhidas pela comunidade, o novo Java EE 5 adere a práticas popularizadas por estas outras soluções, como inversão de controle, uso mais intenso de metadados, e persistência baseada em POJOs (Plain Old Java Objects).

Este artigo inicia com uma discussão geral sobre esta grande atualização da plataforma. Diferentemente de outros artigos desta coluna, não entraremos em

detalhe sobre APIs e funcionalidades es-pecíficas, o que seria pouco viável devido à extensão da plataforma. Esta necessidade será melhor servida por artigos futuros es-pecializados em temas como JPA (coberto nesta edição), EJB etc. Aqui nosso obj etivo é fornecer uma visão conceitual. Mas agora assumimos que o leitor já possui familiari-dade básica com a plataforma J2EE. Assim, podemos enfocar as novidades, e analisar e discutir a natureza e as motivações por trás de cada mudança dessa atualização que pode mudar radicalmente sua rotina de desenvolvimento de aplicações “En-terprise Edition”. E para começar uma exploração prática, o quadro “GlassFish: o Java EE open source” mostra como instalar a implementação de referência (RI) desta plataforma, e desenvolver uma aplicação Java EE 5 simples com o IDE NetBeans 5.5.

Java EE 5: Produtividade Corporativa

Se o release anterior, J2EE 1.4, era a versão dos web services, o Java EE 5 é a versão da produtividade. Não por coincidência, este é o mesmo foco do Java SE 5.0, especial-mente com a nova sintaxe de anotações.

As anotações são o veículo principal das melhorias de produtividade do Java EE 5. Quer que uma classe seja um

Stateless Session Bean? Basta declarar

“@Session class MinhaClasse {...}”. Precisa expor a funcionalidade de uma classe como um web service? Use a tag@WebService. E para conectar a umDataSource? Nada de código JNDI –InitialContext,lookup(),narrow(), trata-mento de exceções – basta usar a anotação apropriada, como:

@Resource(name= ”jdbc/minhaDS”) DataSource minhaDS;

POJOs e anotações versus descritores

O paradigma de programação do Java EE 5 dá um guinada espetacular,

abandonan-É

comum que problemas complexos tenham soluções complexas, e as opções que parecem mais simples às vezes não escalam com as de-mandas das aplicações com mais “complexidade essencial”. A plataforma J2EE foi por muito tempo vista como “canhão para matar mosca”: aplicações mais simples, sem necessidades avançadas de integração, escalabilidade, segurança etc., eram mais bem servidas por concorrentes mais leves e produtivos. Mas não deveríamos ter que migrar para outra plataforma – perdendo investimentos de código, treinamento e ferramentas – conforme cada projeto for mais simples ou complexo.

Tanto o velho J2EE quanto os competidores mais simples (ex. Ruby on Rails) exibem a falta de uma qualidade que poderíamos chamar de “escalabilidade de complexidade”: a mesma plataforma deveria comportar o desenvolvi-mento de uma grande gama de aplicações, das mais triviais até as mais sofisticadas. E recursos

avançados devem estar disponíveis para quem precisar, mas sem impor esforço de desenvol-vimento extra para aplicações com requisitos mais modestos.

O Java EE 5 é bem mais escalável quanto à complexidade. Por um lado, quando você tiver problemas muito complexos para resolver, as qualidades “enterprise” continuam lá: todo o poder dos EJBs, além de segurança declarativa, transações distribuídas, conectores, web ser-vices, JNDI, clusters etc. Já aplicações simples serão codificadas de forma simples. No J2EE tradicional, artefatos burocráticos acabavam constituindo uma fração significativa do código de aplicações de menor porte, ridicularizando o J2EE em cenários “alô mundo”. Com o Java EE 5 isso deixa de acontecer. E mesmo para as aplicações mais ambiciosas, a facilidade de pro-gramação do Java EE 5 deverá ser sensivelmente maior em comparação com o J2EE 1.4.

Complexidade escalável

(19)

do boa parte da burocracia do tradicional J2EE em favor de uma opção preferencial pela simplicidade. A “programação base-ada em POJOs1_{” é fortemente suportada.}

Veja algumas novas características:

•Temos POJOs no lugar de

implementa-ção de interfaces. Não precisam mais ser escritos centenas de métodos completa-mente vazios, comoejbActivate(), só porque uma interface de EJB os exige.

•É usada a Injeção de Dependências em

vez de aborrecidos lookups na JNDI.

•As anotações assumem o lugar de

des-critores XML.

•Há muitos comportamentos default que

evitam a necessidade de especificar op-ções comuns, seja com descr itores ou com anotações. Por exemplo, um @WebMethod (método de web service) suporta anotações @WebParam para os parâmetros, mas estas são opcionais. Na sua falta, o container assumirá defaults bons para a maioria dos usos (comoholder=Mode.IN).

Mas será que este paradigma de progra-mação é sempre melhor? Em relação às anotações, que são o instrumento funda-mental do novo modelo, já as questiona-mos em artigos anteriores, em seções com títulos como “Cuidados com as anotações” e “Uma crítica às anotações”. O motivo de tanta precaução é que uma revisão tão radical no processo de desenvolvimento não deve ser abordada sem cuidado e visão crítica.

Felizmente, com a forma que o Java EE 5 tomou, esses temores não se concretiza-ram. Em especial, os descritores ainda são suportados (o que já é bom por motivo de compatibilidade) e eles têm prioridade sobre informações declaradas por anotações. Isso evita que as anotações eliminem a flexibilidade garantida pelos descritores.

Por exemplo, numa classe persistente você pode usar uma anotação@Table(name=”TAB”) para determinar que os objetos da classe serão persistidos na tabela “TAB”. Isso é muito conveniente, mas o que acontece se um dia o nome da tabela t iver que mudar? No J2EE tradicional (EJB/CMP), bastaria alterar o descritor. No Java EE 5 podería-mos alterar a anotação@Table,mas isto não é obrigatório. Podemos também criar um descritor e informar nele o nome atuali-zado da tabela. No caso de redundância

(mesma informação em anotações e no descritor), o container dará preferência ao descritor. Preserva-se assim a flexibilidade dos descritores – e só há o trabalho de manipulá-los quando isso for realmente necessário.

Mas note que estes casos são a minoria. Na prática, as oportunidades de adap-tar aplicações a mudanças no ambiente externo mexendo apenas no descritor só costumam ocorrer em casos triviais, como mudanças nos nomes JNDI de DataSources ou filas de JMS, causadas talvez por uma migração de ambiente (ex.: homologação para produção). E mesmo nestes casos, a indireção proporcionada pelasresource

re- ferences (J2EE 1.3+) já evita a necessidade de

alterações até nos nomes JNDI “internos”, usados nos descritores e no código.

Observamos que existem algumas ca-racterísticas, consideradas “estruturais”, que se definidas por anotações não são redefiníveis por descritores. Por exemplo, novamente com EJBs, anotações como @Stateless e@Stateful denotam os diferentes tipos de Session Beans. Mas se uma clas se for anotada com@Stateless, não será possí-vel, pelo descritor, transformá-la num EJB Stateful. O motivo é simples: a diferença entre um bean Stateless e um Statefu l não está apenas no descritor – beans Stateful, presumivelmente, mantêm algum estado interno, enquanto beans Stateless não o fazem, portanto transformar um tipo no outro exige alterações de código de qual-quer maneira.

Anotações versus Orientação a Objetos

As anotações constituem uma alter-nativa a técnicas mais tradicionais na programação OO, como herança ou design patterns. O J2EE tradicional, como sabemos, é fortemente baseado em herança. Um Entity Bean, por exemplo, é uma classe que implementa a interface javax.ejb.EntityBean, o que obriga a definir sete métodos (como ejbActivate(), ejbLoad() etc.), que na sua maioria são desneces-sários para a maior parte dos beans. Há certamente algo errado numa arquitetura que obriga as aplicações a definir até sete métodos vazios para cada entidade de negócio. (Lembrando que em Java, nem sempre é uma boa idéia usar classes-base que forneçam implementações default

destas interfaces de framework, pois isto “queima” a oportunidade única de herança de implementação2_).

Em oposição à rigidez da herança, as anotações enriquecem uma classe com comportamentos de forma muito mais granular. Há anotações por tipo, atributo, método, e até por parâmetro ou variável local. Assim, se o seu bean realmente pre-cisa executar algum código especial após a ativação, basta implementar um método anotado por@PostActivate.

As anotações possuem uma vantagem crucial:são estaticamente tipadas. Podem ser verificadas e validadas de forma

offline, o que evita toda uma categoria

de bugs. O javac só verificará a correção

sintática das anotações, por exemplo re-clamando se você usar uma propriedade inexistente numa anotação; não reportará erros semânticos, ex.: uma propriedade @EJB.beanInterface com um valor que não seja uma interface local/remota de EJB. Mas as ferramentas de validação incluídas em IDEs com suporte a Java EE e em ser-vidores de aplicações poderão fazer estas validações no momento da implantação ou antes, evitando que o bug fique oculto e “estoure” somente quando a aplicação já estiver em operação.

Injeção de Dependências

A persistência de POJOs, no estilo do Hibernate, tem chamado atenção como a grande novidade que o Java EE 5 pega emprestada de outros frameworks. Mas não menos importante é a Injeção de De-pendências (ID). Para compreender a idéia fundamental da ID, podemos classificar as

1_{Plain Old Java Objects}_{, algo como “bons e velhos}

obje-tos Java”. É uma deﬁnição por exclusão: objeto s que não são obrigados a herdar/implementar nenhuma interface imposta por uma API. Também se usa POJI para interfaces que não precisam herdar nenhuma outra interface. Um framework que suporta POJOs, no lugar de herança, uti-liza mecanismos mais fracamente acoplados, como ano-tações ou arquivos de conﬁguração, para interagir com seus objetos.

2_{A exceção ﬁca por conta de casos simplistas como os}

listeners da AWT/Swing, ex.:MouseListener, acompanhados por classes “adapter”, comoMouseAdapter, que facilitam a criação deinner classes que implementam somente um dos métodos exigidos por listeners que agrupam vários eventos. Como tratadores de eventos são simples e rara-mente se beneﬁciariam de herança de implementação, nestes casos não faz mal usar a herança única para deri-var do adapter. O mesmo não pode ser dito de EJBs que implementam complexas regras de negócio.

(20)

aplicações em três graus de evolução: 1. Todas as dependências (de confi-gurações e de código) estão amarradas no código. Neste caso, mudar qualquer coisa exige alterar código, recompilar e reiniciar a aplicação. É o grau zero, hoje em dia só encontrado em aplicações de iniciantes ou em códigos descartáveis, como protótipos.

2. Dependências de configuração estão fora do código. A aplicação é parametri-zada por informações carregadas a partir de arquivos, bancos de dados, diretórios ou outros locais externos. A alteração destes parâmetros pode ser feita por um não-desenvolvedor, não exige mudanças no código e talvez nem indisponibilidade do sistema. Por outro lado, dependências de código continuam amarradas. Em qualquer circunstância onde a classe A precisa utilizar a classeB, isto é feito com código, ex.: class A { void m() { B b = new B(); // usa b... } }.

Alguns design patterns, como Abstract Factory e Service Locator, ajudam a encap-sular e concentrar num só lugar a decisão de quais objetos instanciar ou utilizar, e permitem aos dependentes de um com-ponente depender apenas de interfaces abstratas. Mas isso não é uma solução completa, pois as dependências de código continuam sendo resolvidas por código, ainda que de forma mais elegante e sem repetições. É neste ponto de evolução que se encontra a maioria das aplicações atuais bem escritas.

3. Uso de Injeção de Dependências. As dependências de código não são respon-sabilidade do código da aplicação, e sim de um runtime de Injeção de Dependên-cias, que “injeta” em cada objeto-cliente os recursos dos quais ele depende. As regras que determinam como esta injeção é feita – qual classe instanciar e com quais parâmetros – ficam em metadados exter-nos, que são manipulados pelo runtime de ID.

O exemplo mais comum de Injeção de Dependências, em aplicações Java EE, é

o da comunicação com EJBs. Se você já programou com EJB, já deve ter visto ou es-crito muito código como o daListagem 1. Neste exemplo, na camada de apresentação de uma aplicação (no caso, uma GUI web implementada com o Struts), precisamos invocar um Session Bean que executa o login do usuário. Todo o código destacado em negrito não passa de “burocracia do J2EE”. Veja quanta coisa precisamos fazer só para invocar um simples métodologin() no bean remoto:

•Configurar a conexão com a JNDI

(sim-plificado, neste código – pode ser preciso setar propriedades para o InitialContext).

•Fazer um lookup na JNDI.

•Tratar possíveis erros deste lookup. •Como o que é retornado pelo lookup

é na verdade a interface Home, deve-se invocar um dos seus métodoscreate() para gerar a referência ao Session Bean que realmente desejamos.

•Se estivermos usando uma interface

remota, ainda precisamos usar a operação narrow() ao invés de um simples typecast do Java.

•Finalmente, como estes lookups são

relativamente custosos, aplicações preo-cupadas com o desempenho devem tentar reduzi-los, por exemplo com a estratégia de cache e inicialização sob demanda ilustrada com o método lookupLoginServer() e o atributologinServer.

Por essas e outras, os únicos desenvolve-dores que acham o EJB simples costumam ser aqueles que já utilizaram gerações ante-riores de componentes distribuídos, como o COM/COM+ da Microsoft ou o CORBA da OMG. Há justificativas para expor algumas das etapas que descrevemos, mas nem sem-pre. Por exemplo, nunca entendi a utilidade da interface Home para Stateless Session Beans, que só podem ter um métodocreate(), sem parâmetros e cujas invocações retor-nam sempre a mesma referência.

Mais grave é nos obrigar a escrever código que quase nunca é necessário. Por exemplo, quanta gente trata exceções como NamingException, com um código de recuperação de falha específico a cada local de ocorrência? Quase ninguém; o que todo mundo faz é tratar de forma genérica estas exceções, talvez encapsulando-as em outra exceção que o framework utilizado sabe tratar (como umaServletException para aplicações web). Daí o framework se en-carrega da exceção, cancelando a operação em andamento, roteando a GUI para uma página de erro configurável, etc. Mas se é para deixar que o framework ou o con-tainer trate exceções, não deveríamos ter que escrever centenas de blocos try/catch exatamente iguais, nem saber que existe aNamingException! Aliás, nem deveríamos precisar lidar com a JNDI, ou as interfaces Home, exceto em casos excepcionais.

Listagem 1.Código de exemplo numa Web Application J2EE que acessa um servidor EJB.

public class LoginAction extends DispatchAction // usando Struts

protected LoginServer loginServer ;

protected synchronized LoginServer lookupLoginServer () throws ServletExcep tion

{

if (login == null) try {

InitialContex t ctx = new InitialContex t();

Object obj = ctx.lookup(“ ejb/session/L oginServer”) ; LoginServerHo me home = (LoginServerH ome)

PortableRemot eObject.narr ow(obj, LoginServer Home.class); loginServer = home.create();

}

catch (final NamingExcept ion e) { throw new ServletExcept ion(e); } return login;

}

public ActionForward doLogin (final ActionMapping mapping, final ActionForm form, final HttpServletRe quest request, final HttpServletR esponse response)

throws ServletExcep tion {

LoginServer loginServer = lookupLoginServer(); LoginForm f = (LoginForm)form;

boolean ok = loginServer. login(f.getUs er(), f.getPassword ()); // ... etc.

} }

(21)

Figura Q1. Criando o projeto de exemplo.

para o GlassFish, utilizando o plug-in disponível emglassfishplugins.dev.java.net , mas o WTP (e versões anteriores do NetBeans) ainda não possui suporte específico para o Java EE 5.

O NetBeans pode ser baixado numa versão que já inclui o servido r Java EE, que desta forma é pré-configurado na instalação, ou se pode instalar o Glassfish à parte. Neste caso, será preciso ir em

Tools > Server Manager > Add Server e criar um novo registro do tipo Sun Java System Application Ser-ver, entrando com seus parâmetros de instalação (diretório, login de administrador etc.). (Este mes-mo tipo de servidor funciona com o Java EE SDK 5.0 / SJSAS 9 e com o Glassfish; par a simplificar, nos referiremos ao servidor como apenas “GlassFish”.) Agora vá na janelaRuntime do NetBeans e, sob

Servers, encontre o servidorGlassFish e comande

Start in Debug Mode.

EmFile | New Project , selecioneEnterprise / Enter- prise App lication na primeira página, e preencha a segunda conforme aFigura Q1(modificando é claro os drives e diretórios), selecionando o GlassFish e criando um módulo EJB e um módulo web. O NetBeans criará três projetos, para os mó-dulos EJB, WAR e EAR.

No projeto EJB, acioneNew > Session Bean, e crie um EJB com nome “Alo”, tipoStateless e interface apenasRemote. O assistente irá criar os fontes da interfaceAloRemote e da implementaçãoAloBean. Após customizarmos estes fontes, eles deverão ficar como nasListagens Q1 e Q2.

Examinando o projeto, você verá que temos apenas estes dois arquivos.java, e além disso dois descritores –sun-ejb-jar.xml eMANIFEST.MF . Mas ambos estão vazios; foram criados apenas por conveniência. Apague estes dois arquivos do projeto, para comprovar o que dissemos sobre serem opcionais.

No projeto do EAR, acioneDeploy Project . O NetBeans irá executar a compilação dos módulos dependentes, o empacotamento do EAR, e sua

GlassFish:

T

u

t

o

r

i

a

l

O Java EE 5

O

Java EE 5 é um padrão formal do JCP, e logo terá muitas implementações concorrentes. Mas vale a pena dar uma atenção privilegiada para uma destas implementações, o projeto GlassFish. Trata-se do mais novo servidor Java EE 5 de fonte aberto. Aliás, o único por ora, já que o JBoss, apesar do pioneirismo com o EJB 3.0, ainda não parece perto de finalizar o suporte para a Java EE 5 como

um todo, e o Geronimo provavelmente demorará muito mais.

O GlassFish foi baseado em código doado pela Sun, sendo a base do Sun Java System Application Server 9 (também conhecido como Java EE SDK 5), que é a implementação de referência (RI) do Java EE 5. Tanto a versão open source quanto a da Sun são certificadas. O GlassFish vem sendo desenvolvido como um projeto do portal java.net, onde já angariou bastante suporte da comunidade open source. Resta saber se isso se traduzirá em ganhos significativos de mercado para es te servidor, que até hoje, a despeito da liderança da Sun no desenvolvimento da tecnologia J2EE / Java EE e fortes resultados recentes de benchmarks SPEC jAppServer 2004, tem amargado pouca popularidade, apesar de gratuito para uso comercial (um apelo que se mostrou insuficiente, já que o

JBoss é tanto gratuito quanto open source).

Testando o Java EE 5 com o Glassfish

Para exercitar um pouco os novos recursos do Java EE 5 apresentados neste artigo, veremos uma apli-cação “alô mundo” de duas camadas, com uma interface web JSF que invoca um Session Bean

– executando no GlassFish.

Para este exercício, utilizare mos o IDE NetBeans 5.5. Usuários do Eclipse 3.2 / WTP 1.5 também podem desenvolver