Wednesday, October 18, 2017

DataSource no servidor WildFly utilizando JPA, JSF, Maven e Eclipse: parte 1

Aplicações Java Enterprise acessam banco de dados utilizando a API JDBC. Nela os bancos de dados são acessados usando objetos do tipo DataSource, os quais possuem uma série de propriedades que identificam o banco de dados real como a URL do servidor, o nome do banco de dados, senha, etc.

Antes de acessar o banco de dados, a aplicação precisa criar uma conexão, e um objeto DataSource funciona como um factory de conexões entre o banco e a aplicação. Quando o DataSource é gerenciado pelo servidor de aplicações, geralmente a ele é associado um JNDI, que é um nome para o datasource. Assim quando a aplicação demanda uma conexão, ela utiliza o JNDI, o servidor instancia o(s) objeto(s) DataSource e disponibilizam a conexão.

Datasources em servidores Java EE geralmente implementam o poolingque são algoritmos de instanciação de DataSources totalmente transparentes à aplicação os quais otimizam a liberação, abertura e fechamento de conexões com o banco de dados.

DataSources para o banco de dados MySQL no servidor WildFly 10

Faça download da API JDBC do MySQL (mysql-connector-java-5.1.21.jar) e, caso necessário, baixe também o servidor WildFly 10 Java EE7 Full & Web Distribution . Crie um banco de dados chamado EmpresaBD.

No WildFly, DataSources também são chamados de módulos. Assim, para acessar o MySQL precisamos instalar um novo módulo para ele. No diretório raiz do WildFly, há a pasta modules. A partir dela crie os diretórios /com/mysql/main/ da forma que segue:

WILDFLY_HOME/modules/com/mysql/main/

Dentro da pasta main cole o driver do MySQL que você baixou e crie um arquivo chamado module.xml, o qual conterá a definição do módulo cujo nome é com.mysql. 

A variável JBOSS_HOME aponta para pasta module e os arquivos e pastas criados lá dentro serão usados para carregar o datasource quando o servidor iniciar. O conteúdo do arquivo module.xml deve ser como segue:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql"> 
    <resources>
        <resource-root path="mysql-connector-java-5.1.21.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

A estrutura de diretórios que criamos então fica dessa forma:
  • WILDFLY_HOME/modules/com/mysql/main/mysql-connector-java-5.1.21.jar
  • WILDFLY_HOME/modules/com/mysql/main/module.xml
O módulo para o MySQL está instalado. Agora só precisamos criar o data source para o banco EmpresaDB. Precisamos editar o arquivo standalone.xml passando as coordenadas do banco. Esse arquivo está localizado em:
  • WILDFLY_HOME/standalone/configuration/standalone.xml 
Abra esse arquivo, localize a tag <dataSources> e dentro dela cole o seguinte trecho (ajustando usuário e senha de acordo com suas configurações pessoais):
<datasource jta="true" jndi-name="java:jboss/datasources/empresaDB_DS_mysql"
 pool-name="empresaDB_DS_mysql" enabled="true">

 <connection-url>jdbc:mysql://localhost:3306/EmpresaDB</connection-url>
 <driver-class>com.mysql.jdbc.Driver</driver-class>
 <driver>mysql</driver>
 <security>
  <user-name>root</user-name>
  <password>P@ssword1</password>
 </security>

</datasource>

Ainda dentro da tag <dataSources> localize a tag <drivers> e dentro dela cole este trecho:
<driver name="mysql" module="com.mysql"/>
Repare que a tag driver aponta para o módulo que criamos. E o datasource que criamos aponta para a esta tag driver cujo nome é mysql.

Pronto. Inicie o servidor WildFly executando o arquivo standalone.sh (para Linux) ou standalone.bat (para Windows) localizado em WILDFLY_HOME/bin/

Acesse o console do servidor na porta 9990. Clique na aba Configurations, depois vá clicando em Subsystems, DataSources, Non-XA. Localize o datasource criado EmpresaDB_DS_mysql e teste a conexão. Conforme a imagem:



Repare que o nome que registramos, empresaDB_DS_mysql, é o que será usado na aplicação para que ela solicite ao servidor uma conexão com o banco de dados EmpresaDB.

Na parte 2 criamos uma aplicação JavaEE que acessa o DataSource.

Referências:
ĆMIL , Michal; MATLOKA, Michal ; MARCHIONI, Francesco . Java EE 7 Development with WildFly. 2. ed. Birmingham: Packt Publishing Ltd., 2013

Access restriction: The type 'Application' is not API (restriction on required library '/usr/lib/jvm/jdk1.8.0_144/jre/lib/ext/jfxrt.jar')

Recentemente ao criar um projeto JavaFX no Eclipse, a IDE disparava uma advertência sempre que eu tentava importar algo do pacote javafx.*


Para corrigir isso, vá em propriedades do projeto. Na janela que abrir selecione Java Build Path, vá na tab libraries e expanda o item JRE System Library, conforme a imagem:


Selecione o item Access Rule e depois o botão Edit.... Na janela que abrir clique no botão Add... .Na caixa de texto Rule Pattern coloque javafx/** e na combo box Resolution escolha a opção Accessible Conforme a imagem:


Clique em OK, Apply e OK. Limpe e construa seu projeto novamente. As advertências deixam de aparecer.



Monday, October 16, 2017

Generic Lazy Loading com JSF e PrimeFaces

Lazy Loading é um padrão de projeto que atrasa o carregamento de dados na memória até o momento quando eles são estritamente necessários. Em sistemas orientados a objeto, as entidades estão sempre relacionadas umas com as outras de modo que esses níveis de relacionamento podem se extender indefinidamente dependendo do tamanho do sistema. Se a aplicação não implementa uma estratégia adequada para listar os registros em uma tabela, ela corre o risco de carregar uma quantidade absurda de dados na mémória sem necessidade, o que pode prejudicar seu desempenho.

O componente p:dataTable do framework PrimeFaces permite implementar LazyLoading de forma muito simples bastando que o desenvolvedor estenda LazyDataModel<T>, onde T é o tipo da entidade que será carregada na tabela. Por exemplo, suponha que você tenha uma entidade Pessoa, você deveria extender LazyDataModel da seguinte forma:
public class LazyTablePessoa extends LazyDataModel<Pessoa>{

   private PessoaService service;

   @Override
   public List<Pessoa> load(int first, int pageSize, String sortField, 
                               SortOrder sortOrder, Map<String, Object> filters) {

     
        List<Pessoa>listPessoa = pessoaService.getPessoas(first, first + pageSize);
        int linhas = pessoasService.countPessoas();
        setRowCount(linhas);
        return listPessoa;
    }
  //... outros métodos
}
Essa abordagem possui um problema se o projeto for crescendo e um número cada vez maior de entidades demandar lazy loading em determinadas telas. Dessa forma seria necessário implementar  LazyDataModel para cada entidade que você queira exibir. Se houver 100 entidades para listar, você terá que implementar 100 extensões de LazyDataModel, cada uma com o código praticamente idêntico!

Generic Lazy Data Table
Somente os dados exibidos são carregados na memória.

Podemos reduzir drasticamente essa quantidade de implementações criando uma única extensão genérica de LazyDataModel que atenda, digamos, 90% de todas as necessidades de exibição, ou seja, você podera ter 100 entidades no seu modelo, mas uma única implementação de LazyDataModel será suficiente para listar as entidade de acordo com o padrão lazing.

Para implementar este padrão precisamos criar:
  1. Uma DataTable genérica que extenda LazyDataModel
  2. Uma interface de serviço genérica que busque os dados. As especificações de busca para cada entidade variam de acordo com a implementação.
O diagrama de classes abaixo resume o modelo:


Implementando o diagrama

Pessoa.java
public class Pessoa {
    
    private String nome;
    private int idade;
    private Date nascimento;

    //métodos getters & setters
}

GenericService.java
public interface GenericService<T> {
    //a quantidade de registros que serão carregados
    List<T> buscaPaginada(int inicio, int fim);
    //a quantidade de registros na fonte de dados
    int countLinhas();
}
PessoaService
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class PessoaService implements GenericService<Pessoa>{

    //representando o banco de dados
    private List<Pessoa> dataSource;
    
    public PessoaService() {

        dataSource = new ArrayList<>();
        for(int i = 0; i < 100; i++){
            Pessoa p = new Pessoa();
            p.setNome("Pessoa "+i);
            p.setIdade(i);
            p.setNascimento(new Date());
            dataSource.add(p);
        }        
    }    

    //implementação para a entidade pessoa
    //as regras podem variar de entidade para entidade...
    @Override
    public List<Pessoa> buscaPaginada(int inicio, int fim) {        

        return dataSource.subList(inicio, fim);
    }

    @Override
    public int countLinhas() {

        return dataSource.size();
    }    
}

Nossa implementação de GenericLazyDataTable

import java.util.List;
import java.util.Map;
import org.primefaces.model.LazyDataModel;
import org.primefaces.model.SortOrder;

public class GenericLazyDataTable<T> extends LazyDataModel<T>{
        
    private final GenericService genericService;

    public GenericLazyDataTable(GenericService genericService) {

        this.genericService = genericService;
    }

    @Override
    public List<T> load(int first, int pageSize, String sortField, SortOrder sortOrder, Map<String, Object> filters) {

        int linhas = genericService.countLinhas();
        this.setRowCount(linhas);
        return genericService.buscaPaginada(first, first + pageSize);
    }    
}

O managed bean controller da página JSF
import java.io.Serializable;
import javax.annotation.PostConstruct;
import javax.faces.view.ViewScoped;
import javax.inject.Named;

@Named
@ViewScoped
public class ManagedBean implements Serializable{
    
    private GenericLazyDataTable genericLazyDataTable;
    private GenericService genericService;    

    @PostConstruct
    public void init(){        

        genericService = new PessoaService();
        genericLazyDataTable = new GenericLazyDataTable(genericService);
    }

    public GenericLazyDataTable getGenericLazyDataTable() {

        return genericLazyDataTable;
    }        
}

E a página inicial index.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:p="http://primefaces.org/ui"
      xmlns:f="http://xmlns.jcp.org/jsf/core">
    <h:head>
        <title>Lazy Pessoa</title>
    </h:head>

    <h:body>
        <p:dataTable value="#{managedBean.genericLazyDataTable}" var="pessoa" lazy="true" rows="20" paginator="true">

            <p:column headerText="nome">
                <h:outputText value="#{pessoa.nome}" />
            </p:column>

            <p:column headerText="idade">
                <h:outputText value="#{pessoa.idade}" />
            </p:column>

            <p:column headerText="nascimento">
                <h:outputText value="#{pessoa.nascimento}" >
                    <f:convertDateTime pattern="dd/MM/yyyy" locale="pt" />
                </h:outputText>
            </p:column>

        </p:dataTable>
    </h:body>
</html>

Estrutura do projeto na IDE NetBeans 8.1 (utilizando Maven)


Tornando a implementação ainda mais genérica

É possível tornar esse modelo ainda mais genérico. Por exemplo poderíamos criar um campo Map em GenericLazyDataTable e sobrecarregar o método buscaPaginada de GenericService para definir filtros de busca. Algo como: 
private Map<String, Object> filtrosPersonalizados;

//outros campos...

//pode ser chamado pelo Managed Bean
public void adicionarFiltro(String nomeDocampo, Object tipoDoCampo) {

        filtrosPersonalizados.put(campo, object);
}

Friday, July 28, 2017

Atualizando a variável JAVA_HOME no Linux

JAVA_HOME é uma variável de ambiente que aponta um diretório JDK no seu sistema. Essa variável é utilizada como referência por vários aplicativos que usam o java para rodar. Se ela não existir ou estiver incorretamente configurada, muitos aplicativos podem não executar.

O arquivo home/.bashr contém o script the execução além de vários parâmetros para iniciar o shell bash, que é a versão mais comum em Linux para terminais de linhas de comando. Para atualizar a JAVA_HOME anexamos o camando export no final do arquivo .bashr junto com o novo valor da variável.

Suponha que você baixou a última versão do JDK, que hoje é jdk1.8.0_141, no diretório:

/usr/lib/jvm/jdk1.8.0_141/

Utilizando o editor de texto vi, abra o arquivo .bashr
vi .bashr
Adicione no final do arquivo os camandos:

export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_141/
export PATH=$JAVA_HOME/bin:$PATH

No final do arquivo adicionamos o novo valor de JAVA_HOME e exportamos para o PATH
Variáveis de ambiente e de shell são definidas através do comando export. A última linha adiciona a variável JAVA_HOME na variável PATH, a qual mapeia todos os comandos reconhecidos pelo terminal shell bash.

Observação: o editor de texto vi funciona em dois modos, comando e inserção, caso você tenha alguma dificuldade, dê uma olhada aqui. Ou você também pode utilizar outro editor de texto, como o nano por exemplo.

Salve e feche o arquivo. Efetive as mudanças que você acabou de realizar no arquivo .bash utilizando o camando source:
source ~/.bashrc
Pronto! Agora imprima o valor de JAVA_HOME. A saída deve ser semelhante à do comando  java -version:
$ echo $JAVA_HOME
/usr/lib/jvm/jdk1.8.0_141
$ java -version
java version "1.8.0_141"
Java(TM) SE Runtime Environment (build 1.8.0_141-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)
Seu java está atualizado.

Wednesday, July 5, 2017

Adding Commands to Linux PATH

If you know in which directory the command you want execute is, just type the path until .sh file and run it. This might be boring if the path is too long though. A more effective way is creating a script containing the whole command and add it to the environment variable PATH.

In order to know which directories are mapped by the PATH, run:
echo $PATH
A possible output is this:
/home/rafael/bin:/home/rafael/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8 oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin
The mapped directories are split by two points. Some directories are mapped by default. As you can see ~/bin (/home/rafael/bin) is one of these. This means that if we add some scripts in ~/bin, we will be able to run those scripts from anywhere by just prompting the file script name.

Example: Running Wildfly10 server through the PATH

Assuming your Wildfly server is located at /usr/share/wildfly-10.1.0.Final, let's add to PATH two commands, one to start the server and other to start the server client interface whose full path is /usr/share/wildfly-10.1.0.Final/bin/jboss-cli.sh.

We are just going to create one file called wildfly10 (touch wildfly10) to start the server and other called wildfly_cli (touch wildfly_cli) to run the client, each one containing the respective scripts (echo "..."). After that we give permission (chmod 755...) to make these files executable and that's all.

Starting from your home directory, type:
cd bin
touch wildfly10
echo "sudo /usr/share/wildfly-10.1.0.Final/bin/standalone.sh" > wildfly10
chmod 755 wildfly10
touch wildfly10_cli
echo "sudo /usr/share/wildfly-10.1.0.Final/bin/jboss-cli.sh" > wildfly10_cli
chmod 755 wildfly10_cli
Ready! Wildfly command is on your PATH. Let's try it:

First we start the server by prompting wildfly10

And now running the client server:

Prompting wildfly_cli from anywhere we start the client

And accessing server http port:

localhost:9990

You can add any commands you want to the PATH!


Tuesday, July 4, 2017

Casos de Mapeamento de Coleções no JPA

Aplicações corporativas são essencialmente definidas por sua necessidade de colher, tranformar e exibir uma quantidade enorme de informações. Java Persistence API (JPA) é o framework padrão de aplicações java para fazer a ponte entre o domínio orientado a objetos e o modelo relacional de banco de dados.

Coleções do tipo Collection, List, Set, Map são umas das estruturas de dados mais utilizadas e o JPA permite seu mapeamento para o modelo relacional  de forma simples e eficiente. Você só precisa utilizar as anotações adequadas e não se preocupar como as coleções estão sendo representadas no banco de dados! Vejamos os casos mais comuns de mapeamento de coleções, sejam as coleções classes de entidade, classes embutidas ou tipos básicos:

  • Multiplicidade simples entre uma classe de entidade e classes não-entidade (classes embutidadas)
Exemplo: Uma empresa pode ter muitos endereços (Endereço aqui é uma classe embutida):
@Embeddable
class Endereco{}

@Entity
class Empresa{

   @ElementCollection
   Set<Endereco> enderecos; 

//para classes embutidas, utilize @ElementCollection.
}
Opcionalmente você pode especificar como o JPA deve gerar a tabela de coleções no banco de dados fornecendo alguns parâmetros:
@Entity
class Empresa{

   @Id int idEmpresa;

   @ElementCollection
   @CollectionTable(name="logradouro", joinColumns=@JoinColumn(name="emp_id"))
   @AttributeOverride(name="address", column=@Column(name="o_nome_q_vc_quiser"))
   Collection<Endereco> enderecos;
}
No exemplo anterior, para representar a coleção de endereços da empresa, dissemos para o JPA criar uma tabela chamada logradouro. @JoinColumn representa a chave estrangeira.

Usar a anotação @ElementCollection é o mínimo que você precisa fazer para mapear a maioria dos tipos de coleções. Nos próximos exemplos vamos explorar coleções mais sofisticadas utilizando índices.


Multiplicidade indexada (pares chave/valor)


Pares chave/valor são representados pela interface Map. Coleções desse tipo são muito comuns e são utilizadas em praticamente todas as aplicações. O JPA é bastante flexível com tipos Map. As entidades ou classes embutidas podem representar tanto a chave quanto o valor, ou ainda chave e valor podem ser tipos primitivos.

1 Chave e Valor são tipos primitivos


Exemplo: Um funcionário pode ter vários números de telefone e cada número é de um tipo (comercial, trabalho, casa, etc.):

Essencialmente você só precisa da usar a anotação @ElementCollection para resolver seu problema. Todas as outras são opcionais.
@Entity
public class Funcionario{

   @Id private int id;

   @ElementCollection
   @CollectionTable(name="funcionario_telefone") //opcional, define o nome da tabela no banco
   @MapKeyColumn(name="tipo_telefone") ///opcional indica qual coluna armazena achave
   @Column(name="numero") //nome da coluna que armazena o valor
   private Map<String, String> telefones;
   //...
}
2 A chave do Map pode ser uma enum ou uma data
Constantes enumeradas dão mais consistência e legibilidade ao código. Como no exemplo anterior, mas ao invés de usarmos um tipo básico como chave, usamos uma enum. Novamente a única anotação obrigatória é @ElementCollection, mas podemos definir como o valor da enumeration será armazenado no banco de dados, se sob a forma literal ou numérica, assim precisamos utilizar a anotação @MapKeyEnumerated
public enum TipoTelefone {HOME, MOBILE, WORK}

@Entity
public class Funcionario{

   @Id private int id;

   @ElementCollection
   @CollectionTable(name="funcionario_telefone") //opcional, define o nome da tabela no banco
   @MapKeyEnumerated(EnumType.STRING)
   @MapKeyColumn(name="tipo_telefone") ///opcional indica qual coluna armazena a chave
   @Column(name="numero") //nome da coluna que armazena o valor
   private Map<TipoTelefone, String> telefones;
   //...   
}
Caso quisessemos usar como chave o tipo java.util.Date, poderíamos usar a anotação @MapKeyTemporal ao invés de @MapKeyEnumerated.

3 Chave é um tipo básico e valor é uma entidade
Exemplo: Um departamento tem vários cubículos cada qual com um funcionário.
A modelagem tradicional um departamento tem muitos funcionários ainda não atenderia eficazmente esse cenário. O software precisa indexar cubículo e funcionário.
@Entity
public class Departamento{

   @Id private int id;

   @ManyToMany
   @JoinTable(name="DEPT_EMP", joinColumns=@JoinColumn(name="DEPT_ID"),
                    inverseJoinColumn=@JoinColumn(name="EMP_ID"))
                    @MapKeyColumn(name="CUB_ID")
   private Map<String, Funcionario> funcionarioPorCubiculo;
}
4 Chave é o ID da própria entidade que representa o valor do Map
É comum e intuitivo indexar a chave do map pelo ID da entidade. No exemplo anterior o poderíamos usar algum atributo do funcionário como identificador do cubículo ao invés do próprio nome atribuído pelo departamento.
@Entity
public class Departamento{
   @Id private int id;
   @OneToMany(mappedBy="departamento")
   @MapKey(name="id")
                private Map funcionarios;
}
5 Chave é uma entidade e valor é um tipo básico
Exemplo: Atribuir a senioridade de cada funcionário no departamento em um contexto onde o funcionário pode atuar em vários departamentos e a senioridade podendo variar, uma vez que ela é determinada em função do departamento (um funcionário pode ser pleno no setor de desenvolvimento e junior no departamento de infraestrutura...).
@Entity
public class Department{

   @Id private int id;

   @ElementCollectionn
   @CollectionTable(name="emp_senioridade")
   @MapKeyJoinColumn(name="emp_id")
   @Column(name="senioridade")
   private Map<Employee, Integer> seniorites;
   // ...
}

Tuesday, June 6, 2017

Pool de Conexões em Aplicações Web

Aplicações Web que acessam bancos de dados precisam estar preparadas para receber uma avalanche de requisições ou correm sério risco de serem derrubadas. Considere também que estabelecer uma nova nova conexão com o banco de dados para cada requisição do cliente pode ser oneroso e consumir recursos desnecessários tornando esse processo mais lento e diminuindo a performance da aplicação. Imagine, por exemplo, 1 milhão de acessos simultâneos e a própria aplicação ter que ficar abrindo e fechando conexões para cada um...! Esse gargalo pode ser minimizado com uma técnica chamada pooling.

Outra vantagem é que o servidor passa a gerenciar a conexão com o banco de dados, e não mais a aplicação. O software do servidor implementa o conceito de Pool Manager que passa a ser um middleware entre os componentes clientes (uma classe java, uma servlet, EJB, etc) e uma conexão representada com driver JDBC  para algum servidor de banco de dados. Na prática, é criada uma camada adicional entre a aplicação e o servidor de banco de dados, essa camada é o Pool Manager.

O Pool Manager já abre um conjunto de conexões (pool) quando o servidor inicia e, de acordo com o número de requisições à aplicação, procura sempre se antecipar e manter um número maior de conexões disponíveis antes que as mesma sejam solicitadas.

Com o pooling, as operações de conexão são totalmente transparentes à aplicação, de modo que detalhes sobre o banco de dados (usuário, senha, etc), fechamento e abertura de conexões físicas, endereço do servidor de banco de dados, são administradas pelo pool manager. A seguir um exemplo dessa técnica.


Implementando Pooling no servidor GlassFish 4.1 para o MySQL

No MySQL crie um banco de dados chamado Study. Baixe o driver JDBC do MySQL, copie e cole-o no diretório <glassFishHome>/glassfish/lib.

Inicie o servidor GlassFish. Você pode inicia-lo facilmente através de alguma IDE, ou pelo shell (ou prompt) executando o comando abaixo conforme a imagem:
<glassFishHome>/glassfish4.1/bin/ ./asadmin start-domain


Após iniciar o servidor, abra seu browser e acesse a porta 4848, que é o painel de controle visual do servidor:




No menu em árvore à esquerda, navegue por Resources/JDBC/JDBC Connection Pools e clique em New:



No passo 1/2, dê um nome para o seu Pool, escolha javax.sql.Datasource na combobox resource type. E no drive vendor escolha MySql, que é o banco que escolhemos:



Clique em next.
No passo 2/2 marque habilitar ping e agora configuramos os dados da conexão. O painel apresenta duas centenas de parâmetros para informar, mas nosso interesse é apenas nos dados do usuário do banco, senha (se houver), nome do servidor, nome do banco, porta e URL. No meu caso, parâmetros e valores ficaram respectivamente como segue (faça as adpatações necessárias conforme o contexto de seu sistema):

password: 010203
databaseName: study
serverName: localhost
user: root
portNumber: 3306
URL: jdbc:mysql://:3306/study



Clique em Finish. Acesse sua conexão no menu JDBC/Connection Pools e clique em ping para testar a conexão. Se os parâmetros estiverem corretos o ping ira suceder como mostra a imagem:



Agora, no menu esquerdo vá em Resources/JDBC/JDBC Resources e New. Esse será o recurso que será acessado por nossa palicação. Em JNDI Name coloque jdbc/studyDS e na combo box pool name escolha o pool que você acabou de criar, StudyDB e salve.



Agora nosso recurso está disponivel na tabela JDBC Resources do servidor, como jdbc/studyDS. Guarde esse nome pois ele será informado em nossa aplicação.

Acessando o Pool com uma aplicação web

Com uma IDE de su preferência (usei NetBeans 8.2), crie um novo projeto Web Application chamado TestDataSource. Na pasta WEB-INF crie os arquivos web.xml e sun-web.xml. Cole as seguintes tags nos arquivos:

web.xml 
    <distributable/>
    <resource-ref>
        <description>JDBC Connection Pool</description>
        <res-ref-name>jdbc/studyDS</res-ref-name>
        <res-type>javax.sql.ConnectionPoolDataSource</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
sun-web.xml
<sun-web-app>
  <context-root>TestDataSource</context-root>
  <resource-ref>
    <res-ref-name>jdbc/studyDS</res-ref-name>
    <jndi-name>jdbc/studyDS</jndi-name> 
  </resource-ref>
</sun-web-app>
Neste exemplo o componente que irá solicitar conexão ao Pool Manager será uma servlet. Crie uma servlet mapeada para a url NewServlet:
@WebServlet(urlPatterns = {"/NewServlet"})
public class NewServlet extends HttpServlet {

    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
      
        response.setContentType("text/html;charset=UTF-8");            

        try {
            PrintWriter out = response.getWriter();          
            Context ctx = new InitialContext();
//nome do recurso no servidor
         DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/studyDS");
//obtem a conexão do pool                       
            Connection connection = ds.getConnection();                       
//saida mostrando o nome do banco de dados acessado           
            out.println(connection.getCatalog());

           connection.close();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
    }

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        processRequest(request, response);
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        processRequest(request, response);
    }
}
Salve, faça o deploy e acesse aplicação: http://localhost:8080/TestDataSource/NewServlet

Se tudo estiver certo, a aplicação mostra o nome do banco de dados, study pelo método getCatalog() do objeto connection:




Repare que em nenhum momento a própria aplicação toma maiores conhecimentos sobre o banco de dados, tais como usuário, senha, driver ou a localização do servidor, ela simplesmente pede uma conexão não importando de onde ou como ela vem, o que representa uma brecha de segurança a menos no sistema.

Existem formas ainda mais otimizadas para acessar o Pool utilizando as especificações JPA e CDI do JavaEE 7 através das anotações @PersistenceContext @Resource!