Criando um Datasource MySQL no GlassFish

Objetivo

Esta dica é para a configuração de um datasource MySQL no GlassFish.

Os datasources são especialmente úteis quando se pretende criar uma aplicação que deixa a cargo do servidor de aplicações o gerenciamento dos recursos de conexão, podendo contar, por exemplo, com pools de conexão.

Apresentarei como criar e configurar um pool de conexões, e como referenciar o mesmo em um arquivo persistence.xml, para uma aplicação que utiliza a JPA.

Criando o Pool de Conexões

A primeira coisa a fazer é criar um pool de conexões para um banco de dados MySQL. Aqui vamos assumir um banco de dados chamado “agenda1” localizado na mesma máquina que o GlassFish (localhost).

Acesse o console de administração do GlassFish e encontre o menu “Resources”:

Nele há o nó JDBC, e abaixo dele os itens JDBC Resources e Connection Pools.  Vamos acessar primeiramente o item Connection Pools.

Ao clicar neste item será apresentada uma relação dos pools de conexão já criados, e uma opção para cadastrar um novo pool. Escola a opção para cadastrar o novo pool. Uma nova tela será aberta:

Na tela que é apresentada, informe o nome desejado para o pool, o tipo de pool (deve ser ConnectionPoolDataSource) que está sendo criado e o banco de dados destino.

Ao clicar para continuar, uma nova tela será apresentada para a configuração dos detalhes do pool de conexões. Dentre todas as configurações, as mais importantes no momento são as seguintes:

Apesar de não estar preenchido, ainda, é obrigatório informar o nome do banco de dados e a senha para a conexão.

É muito importante que os campos Url e URL estejam igualmente configurados, com o nome do bando de dados ao final da URL.

Após preenchidas as configurações, confirme a criação do pool de conexões. A tela inicial do nó Connection Pools deve apresentar a configuração que você acabou de criar:

Clique sobre ela, para selecioná-la. Na tela que se abre é possível testar a conexão, clicando sobre o botão “Ping”:

Depois de configurar o pool de conexões é preciso criar um recurso JDBC com ele. Acesse o nó “JDBC Resources”. Selecione a opção para criar um novo recurso, e na tela que se abre, escolha um nome para o novo recurso e indique que este recurso é referente ao pool que acabamos de criar:

Depois de confirmar, o recurso aparecerá listado dentre os demais:

Agora, na aplicação que utiliza JPA e será publicada neste servidor, basta referenciar o recurso JDBC no persistence.xml:

Está dada a dica!

Configurando o Tomcat 6.x para acessar uma aplicação EJB3 no GlassFish 2.x

Esta é uma dica rápida, e não um tutorial completo, de como configurar os servidores Tomcat e GlassFish para que uma aplicação web/JSF publicada no Tomcat possa acessar um EJB remoto em um servidor GlassFish.

Não irei apresentar detalhes de como implementar as aplicações (páginas, Managed Beans, EJB, etc…), apenas dar uma dica de como configurar o ambiente para esta interação (bibliotecas, arquivos de configuração, etc…), uma vez que a configuração inicial pode ser “chata” o suficiente para tirar a paciência de qualquer cristão.

As versões usadas nos testes foram as seguintes:

Tomcat 6.0.20

GlassFish 2.1

Imagine o cenário: você quer escrever uma aplicação web, com JavaServer Faces (Richfaces) e publicar esta aplicação no Tomcat. Você quer desenvolver seus EJBs 3.0 e publicá-los no GlassFish, e fazer com que sua aplicação que está no Tomcat possa acessá-los.

O cenário parece simples, acessar remotamente um EJB. O problema são as benditas configurações a serem feitas, e principalmente, a falta de informações detalhadas para este cenário especificamente: Tomcat + GlassFish. Procurando referências de configurações de componentes EJB3.0 no GlassFish chegamos à GlassFish EJB FAQ. Nela encontramos a informação inicial de que, para uma aplicação acessar remotamente um EJB 3.0 no GlassFish precisamos de alguns jars no classpath do projeto:

For GlassFish v2 and earlier

Include both $GLASSFISH_HOME/lib/appserv-rt.jar and $APS_HOME/lib/javaee.jar in the client’s classpath.

E.g., assuming the application classes are in /home/user1/myclasses and the main client class is acme.MyClient :

java -classpath $GLASSFISH_HOME/lib/appserv-rt.jar:$GLASSFISH_HOME/lib/javaee.jar:/home/user1/myclasses acme.MyClient

Note : appserv-rt.jar uses the JAR MANIFEST-CLASSPATH attribute to include other dependent .jars within the lib directory.  When setting your client classpath, it is best to directly refer to the appserv-rt.jar within the app server lib directory rather  than copying it to another location.  If you do copy appserv-rt.jar, you’ll need to copy additional .jars such as  appserv-deployment-client.jar and appserv-ext.jar.  The full set of .jars that might be needed by appserv-rt.jar is located in its META-INF/MANIFEST.MF file.

Para resimir isto aí tudo, para as versões dos servidores que eu citei no início, os jars necessários são os seguintes, encontrados no diretório lib da instalação do GlassFish:

Ok! Se você jogar estes jars diretamente no diretório lib do Tomcat, inúmeras exceções serão apresentadas ao executar a aplicação. Seguindo a dica deste post, deve-se criar um diretório shared/lib na raiz do diretório de instalação do Tomcat, para que estas exceções não ocorram.

O grande problema desta dica é que, segundo o que parece, os jars são reconhecidos automaticamente, mas a realidade é bem diferente. Depois de muito quebrar a cabeça descobri que é necessário configurar este novo diretório, no arquivo catalina.properties, que se encontra no diretório conf do Tomcat. É necessário incluir o caminho para os jars do diretório shared/lib na entrada common.loader, conforme a imagem abaixo:

Essa é a principal configuração. Realmente é simples, desde que se saiba dos detalhes.

Adicionalmente, há outros detalhes importantes:

Se você estiver executando os dois servidores na mesma máquina é preciso alterar a porta HTTP de um deles. Para alterar a configuração da porta no Tomcat para 8082, por exemplo, edite o arquivo server.xml do diretório conf:

Isto já evitará problema de conflito de portas.

Uma outra dica que deixo, agora com relação à configuração da aplicação JSF e suas bibliotecas, é a seguinte: deixe no diretório lib do Tomcat apenas os jars do Mojarra (jsf-api.jar, jsf-impl.jar) e o jstl.jar. As bibliotecas do Richfaces (richfaces-api-3.3.2.GA.jar, richfaces-impl-3.3.2.GA.jar e richfaces-ui-3.3.2.GA.jar) devem ser mantidas no diretório lib da aplicação.

Localizando os EJBs Remotos

Para fazer a localização dos EJBs remotos na aplicação web, deixo como sugestão este método, para se obter o InitialContext:

Observe as duas propriedades comentadas. Por padrão os listeners de IIOP do GlassFish aceitam conexões em localhost e na porta 3700, e não é necessário informar isto caso você esteja rodando os dois servidores na mesma máquina. Caso precise rodar o GlassFish em outra máquina, informe alí naquelas duas propriedades o host e a porta para acessar o GlassFish.

GlassFish em outro servidor

Caso você precise instalar o GlassFish em um servidor diferente, será preciso habilitar o  mesmo para ouvir conexões IIOP no IP do servidor. Para isso é recomendado adicionar uma nova configuração de Listener IIOP, além da que já está configurada por padrão (que está disponível para localhsot e porta 3700). Para fazer isto acesse o seguinte menu, no console de administração do GlassFish:

Na tela que se abre cadastre uma nova configuração de listener, igual a configuração padrão (orb-listener-1), mas alterando o host e a porta. A imagem abaixo mostra uma nova configuração em destaque:

Bom, espero que esta dica ajude a quem está passando por problemas com esta configuração. Como disse procurei não entrar em detalhes de implementação dos projetos. A única dica que deixo é que para Session Bean Locais a injeção de dependência não vai funcionar no GlassFish, ou seja, referências a estes Session Beans anotados com @EJB não funcionarão. É preciso usar interfaces remotas.

Está dada a dica!

Dicas para Java Swing

Esta é uma dica rápida para quem está começando a aprender Java Swing!

O conjunto de componentes presente neste framework da API Java é robusto e avançado, e permite a criação de interfaces gráficas para o usuário com uma alta qualidade. Nas últimas versões da JDK o desempenho do Swing vem melhorando muito, e ainda é comum que empresas recorram a esta tecnologia para a criação de aplicações desktop, ainda que as aplicações web estejam em alta.

A grande flexibilidade e da tecnologia Swing, porém, é muitas vezes uma barreira para quem está começando a aprender a tecnologia Java. Seus componentes baseados no padrão MVC permitem a criação de datasources específicos para os compoentes, assim como renderizadores especializados, e aprender a trabalhar com tudo isso pode dar um bom trabalho.

O que muitos desconhecem, porém, é que a própria JDK vem com exemplos bem interessantes de como criar interfaces baseadas em Swing.

A dica de hoje é o aplicativo SwingSet, presente no diretório de exemplos da JDK. Você pode encontrar o aplicativo no seguinte diretório (onde JAVA_HOME é o diretório de instalção da JDK):

JAVA_HOME\demo\jfc\SwingSet2

Ao executar o arquivo SwingSet2. jar  será iniciada a aplicação:

Ela apresenta exemplos dos principais componentes da API Swing, como os complexos JTable e JTree:

E o melhor de tudo, o código fonte está disponível para a consulta:

Deixo ainda a dica do Swing Tutorial (em inglês) para a consulta. É excelente!

http://java.sun.com/docs/books/tutorial/uiswing/

Está dada a dica. Qualquer hora posto algo específico da tecnologia Swing por aqui.

[]’s

Windows 7 64bits e Eclipse JEE

Neste final de semana resolvi, finalmente, colocar o Win7 64 bits em meu notebook (Itautec W7655). Exitei por um tempo, por preguiça de fazer backups e todas as reinstalações necessárias, e também pelo receio de não ter todos os drivers reconhecidos, uma vez que o site do fabricante não informa o suporte oficial do Win7 (32 bits e 64bits) para todos os dispositivos. Mesmo assim, comprei um HD externo (o que facilitou demais os backups) e mandei ver na formatação.

Para aqueles que tem este modelo de notebook, e que querem também colocar o Win7, fiquem tranquilos – todos os dispositivos foram reconhecidos!

Uma vez que a configuração dos dispositivos foi tranquila, parti para a instalação das ferramentas de desenvolvimento. A instalação do JDK é tranquila, assim como das demais ferramentas usuais.

Com o Netbeans não tive problemas, o suporte é tranquilo, mas com o Eclipse a coisa não é tão direta.

Eu costumo instalar o pacote Eclipse IDE for Java EE Developers, que já traz os plugins necessários para o desenvolvimento web em Java. Porém, não existe uma versão pronta para 64 bits.

Graças a um comentário neste post, consegui configurar facilmente o pacote citado para o sistema 64 bits. A tática consiste em instalar primeiro o Eclipse IDE for Java EE Developers para 32 bits, e depois descompactar, no mesmo diretório, o pacote Eclipse Classic 64 bits por cima do anterior, substituindo os arquivos em comum.

Eclipse Classic (só ele tem suporte para 64 bits no Windows)

Eclipse for Java EE Developers (suporte somente para 32 bits)

Funcionou numa boa, e me poupou o trabalho de instalar cada um dos plugins manualmente.

Segundo o que foi dito no comentário do post de onde peguei a referência, o fato de não se ter disponibilizado uma versão 64 bits do Eclipse for Java EE Developers se deve à falta de equipe para testar a tal versão.

Fica a dica!