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!