Entendendo o Lookup JNDI, java:comp/env

ref:http://blog.billcode.com.br/2011/04/entendendo-o-lookup-jndi.html

Lookup é usado para fazer chamadas a recursos como banco de dados, EJBs, filas etc. Mas acredito que existem algumas dúvidas de como fazer isto, sendo que existem duas formas e diversas configurações.

Tentarei explicar meu entendimento do assunto através de três pontos:
1 – Global JNDI Namespace e lookup direto
(Quando você implanta um recurso é necessário fornecer um nome JNDI o qual fica registrado no Global JNDI namespace do servidor de aplicação)
2 – Lookup portável
(O lookup direto apresenta alguns problemas que podem ser resolvidos com a forma java:comp/env)
3 – Onde estou e para onde vou
(conforme a origem do lookup sua configuração pode mudar, em outras palavras, um lookup partindo de um WAR pode ser diferente de um JAR) 

Considerações:
Como o EJB 3 deixa transparente muito dos conceitos apresentados aqui (e por existir muitas aplicações com versões mais antigas de EJB), aqui será abordado o EJB 2.1 o que pode ser importante para quem apenas usalookup com anotações do EJB 3 e não conhece como seria sem elas.
Download do código no final do post. 

1 – Global JNDI Namespace e lookup direto
Alguns servidores de aplicações (como Websphere e Weblogic) possuem wizards para registrar recursos. Neste post será utilizado o JBoss onde é necessário descritores (XML) ao invés dos wizards.
São estes registros que permitem que os recursos fiquem disponíveis para lookups:

 

1.1 Registrando um acesso ao MySQL
Neste caso precisamos criar o descritor listado abaixo (mysql-ds.xml) e colocá-lo na pasta server/deploy do JBoss:

<datasources>

  <local-tx-datasource>

        <jndi-name>jdbc/MySQLDB</jndi-name>

        <use-java-context>false</use-java-context>

        <connection-url>

jdbc:mysql://myserver:3306/database</connection-url>

        <driver-class>com.mysql.jdbc.Driver</driver-class>

        <user-name>user</user-name>

        <password>pass</password>

        <exception-sorter-class-name>

org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter

</exception-sorter-class-name>

        <metadata>

              <type-mapping>mySQL</type-mapping>

        </metadata>

  </local-tx-datasource>

</datasources>

Desta maneira, o nome JNDI jdbc/MySQLDB estará disponível para qualquer aplicação. Mais adiante será mostrado como é possível consultar os nomes JNDI disponíveis no namespace do servidor.

1.2 Registrando um Session Bean
No momento de implantar um projeto EJB (jar) com seu respectivo descritor (ejb-jar.xml) também é necessário informar um nome JNDI (para cada EJB). E da mesma forma que existe um descritor de banco de dados, existe um descritor (do lado servidor) para os recursos da aplicação EJB (jboss.xml). Este descritor também é conhecido comodeployment plan*.
Obs: No websphere existe um passo no momento do deploy onde é necessário informar estes dados.

Desta maneira, o nome JNDI br/com/billcode/CustomerServiceLocal estará disponível para as aplicações.

Nota:
Para consultar os recursos disponíveis, todo servidor de aplicação possui uma árvore JNDI que pode ser consultada. No caso do JBoss, é possível acessar o jmx-console e selecionar o item JNDIView o qual irá listar os dois recursos implantados: 

Abaixo é exibido como fazer as chamadas a estes dois recursos (partindo da aplicação web – WAR):
- Lookup 1: Chamando a base de dados
- Lookup 2: Chamando o EJB local da aplicação EJB

Para conseguir executar estas chamadas, existem duas formas:
- Chamada utilizando lookup direto (item 1.3) mais o nome jndi disponível no Global JNDI Namespace
- Chamada utilizando um lookup sobre um nome lógico (item 2)

1.3 Lookup direto
É possível de qualquer parte do código iniciar o contexto e fazer uma chamada JNDI. Não é necessário adicionar nenhum comando ou parâmetro nos descritores (web.xml e jboss-web.xml). Abaixo é exibida uma Servlet com as duas chamadas. Mais adiante será explicado alguns dos problemas desta abordagem.

Em resumo, é possível fazer um context.lookup diretamente sobre um nome JNDI disponível no global JNDI namespace do servidor de aplicação.

Mas quais são os problemas deste lookup direto?
Embora seja simples, não é uma boa prática fazer o lookup direto sendo que existem alguns problemas:
- Em ambientes corporativos, geralmente existem servidores exclusivos para banco de dados, onde já pode existir o nome que você fez referência ao seu código (jdbc/MySQLDB)
- Será necessário alterar o código do lookup quando existe a necessidade de mais ambientes, por exemplo jdbc/MySQL_DESENV, jdbc/MySQLDB_TEST ou jdbc/MySQL_PROD
- Pode existir uma equipe de DBA onde eles são responsáveis pela criação da base, bem como definir os nomes dos databases.
- No caso dos EJBs, alguns servidores de aplicação tem formas diferentes na árvore JNDI. Por exemplo, o ejb do item 1.2 no Websphere seria disponibilizado comocell/clusters/cluster1/br/com/billcode/CustomerServiceLocal, em outras palavras, fazer lookup diretonão é portável
- No caso dos EJBs e filas também existe o problema de ser necessário alterar o código fonte para conseguir fazer o deploy da mesma aplicação mais de uma vez.


2 – Lookup portável

Visto os problemas do lookup direto (item 1.3), a solução é definir nomes lógicos para os recursos da sua aplicação os quais devem ser chamados utilizando java:comp/env/nome_lógico.
Existe um custo de desenvolvimento maior inicialmente, sendo que existe a necessidade de descrever a dependência e fazer o mapeamento do nome lógico ao nome físico (JNDI). Mas esta maneira minimiza todos os problemas citados anteriormente, sendo que apenas com alteração no descritor do servidor (deployment plan) será possível referenciar outro nome JNDI. 

Abaixo é listado o código e os descritores que exemplificam o lookup portável. 
Note que alterando apenas o deployment plan do servidor (jboss-web.xml) será possível referenciar outra base de dados. Ou ainda em uma migração para outro servidor de aplicação, apenas este arquivo seria substituído pelo seu correspondente (ex: sun-web.xml para o glassfish)

3 – Onde estou e para onde vou

Sabendo que são necessários os três passos abaixo para fazer um lookup:
- Chamada via java:comp/env/nome_lógico
- Declaração no descritor da aplicação (web.xml ou ejb-jar.xml)
- Mapeamento no deployment plan do servidor (jboss-web.xml ou jboss.xml)

O último ponto e o item que algumas vezes passa despercebido, até mesmo na hora de questionar sobre por que esta ocorrendo um determinado erro no momento do lookup, é entender a origem da chamada e onde se encontra o recurso desejado.
Em outras palavras, como existem diversas possibilidades, é necessário saber qual delas é o seu cenário antes de sair alterando seus descritores e/ou código:


Item 1 e 2) Acessando BASE via WAR / EJB

Descritor (web.xml ou ejb-jar.xml) 

<resource-ref>
   <res-ref-name>jdbc/customerDB</res-ref-name>
   <res-type>javax.sql.DataSource</res-type>
   <res-auth>Container</res-auth>
</resource-ref>

Deployment plan - mapeamento (jboss-web.xml ou jboss.xml)

<resource-ref>
  <res-ref-name>jdbc/customerDB</res-ref-name>
  <jndi-name>jdbc/MySQLDB</jndi-name>
</resource-ref> 

Item 3 e 4) Acessando EJB-Local via WAR / Outro EJB  
Descritor (web.xml ou ejb-jar.xml) 
<ejb-local-ref>
  <ejb-ref-name>ejb/CalculaFreteService</ejb-ref-name>   
  <ejb-ref-type>Session</ejb-ref-type>   
  <local-home>br.com.billcode.service.client.CalculaFreteServiceLocalHome</local-home>
  <local>br.com.billcode.service.client.CalculaFreteServiceLocal</local>
</ejb-local-ref>   


Deployment plan - Mapeamento

WAR (jboss-web.xml)	EJB (jboss.xml)
<ejb-local-ref>      <ejb-ref-name>ejb/CalculaFreteService</ejb-ref-name>      <local-jndi-name>local/CalculaFreteService</local-jndi-name>    </ejb-local-ref>	<resource-managers>   <resource-manager>     <res-name>CepRepositoryLocal</res-name>     <res-jndi-name>java:ejb/CepRepositoryLocal</res-jndi-name>   </resource-manager> </resource-managers>

Item 5 e 6) Acessando EJB-Remoto via WAR / outro EJB 
Descritor (web.xml ou ejb-jar.xml)

<ejb-ref>
  <ejb-ref-name>ejb/BuscaCep</ejb-ref-name>
  <ejb-ref-type>Session</ejb-ref-type>
  <home>br.com.billcode.service.client.BuscaCepHome</home>
  <remote>br.com.billcode.service.client.BuscaCep</remote>
</ejb-ref>

Deployment plan - Mapeamento (jboss-web.xml ou jboss.xml)
<ejb-ref>
  <ejb-ref-name>ejb/BuscaCep</ejb-ref-name>
  <jndi-name>jnp://server:1099/br/com/billcode/service/BuscaCep</jndi-name>
</ejb-ref>

Item 7) Acessando EJB-Remoto via Aplicação cliente (fora do servidor)

É necessario informar os dados do servidor ao iniciar o contexto:

Hashtable environment = new Hashtable();
environment.put(Context.INITIAL_CONTEXT_FACTORY, 
    "org.jnp.interfaces.NamingContextFactory");
environment.put(Context.URL_PKG_PREFIXES, 
    "org.jboss.naming"); 
environment.put(Context.PROVIDER_URL, 
    "jnp://server:1099");

InitialContext context = new InitialContext(environment);

Sobre o contexto é possível chamar o JNDI: 

Object obj = context.lookup("br/com/billcode/service/BuscaCep");





Download dos exemplos:
Ambiente: jdk 1.6.24, jboss 6.0, eclipse 3.6
1 - Lookup direto
2 - Lookup portável (bom uso das chamadas)

Considerações:
- O código exemplo tem como objetivo mostrar chamadas JNDI, não é o foco deste post, mas para melhorar seu código que faz chamadas a recursos, adicione o padrão de projeto ServiceLocator ou utilize injeção de dependência.

* Deployment plan: 
É o descritor do servidor de aplicação, geralmente existem 2, um para aplicações web e outro para aplicações enterprise. Exemplos: 
JBoss – jboss-web.xml e jboss.xml 
Weblogic – weblogic-web.xml e weblogic.xml 
Glassfish – sun-web.xml e sun-ejb-jar.xml 

How to Use GIT

Master Repository	The place where you upload your 'Committed' files.
Local Repository	The Place on your computer where you save and work on files.
State/Revision	Basically a save file of your repository (they never have overwrite)
Commit	Stores your files to a 'state/revision' on your 'local repository'. These commits serve as nodes.
Nodes	'save files' of commits to the repository. Nodes automatically 'Branch' off of the 'Master Repository'.
Branch	Both a verb and a noun, referring how GIT branches off 'nodes' when users commit their files
Head	The most recent 'node' on a 'branch'
Merge	Combines 2 'branch heads' together into 1 branch (usually with the 'Master Branch')
Push	Uploads or sends all of your 'commits' to the 'Master Repository'.
Fetch	Downloads all of the 'commits' from the 'Master Repository' to your 'Local Repository'. (DOES NOT MERGE)
Pull	Downloads or 'Fetch'es all of the 'commits' from the 'Master Repository' to your 'Local Repository' and 'Merges' your most recent commit.
GIT four step process	Fetch - Merge - Commit - Push

Maven 3.2.5 - Configiguração no Eclipse

Para integrar o Maven com o  Eclipse,  acesse o menu      Window > Preferences >  Maven > Installations

Veja que já existe uma instalação “embarcada”, mas com uma versão desatualizada.

Vamos a configuração

Clique em Add... e selecione a pasta com a nossa instalação, no caso: C:\POC\apache-maven-3.2.5.

Vá até o menu User Settings e visualiza o arquivo de configurações e a localização do repositorio:

Maven 3.2.5 - Configurar proxy e o local do repositório no Maven

O Maven é configurado através do arquivo settings.xml que fica no diretório C:\apache-maven-3.2.5\conf.

Proxy

Para confiturar o proxy procure a tag <proxy>, a qual deve estar comentada no arquivo de configuração e adicione as informações abaixo:

<proxy>

<id>optional</id>

<active>true</active>

<protocol>http</protocol>

<username>Usuario_DOMINIO</username>

<password>Senha_Usuario</password>

<host>IP_DO_PROXU</host>

<port>PORTA</port>

<nonProxyHosts></nonProxyHosts>

</proxy>

Substituir o nome de usuário e senha pelos respectivos.

 

Local do repositório

O Maven utiliza um diretório local para baixar os artefatos da internet. O diretório padrão fica dentro pasta do usuário, na pasta .m2.

Um exemplo no Windows é c:\users\%usuario%\.m2\repository.

Para isso, basta editar o settings.xml, movendo a tag <localRepository>para fora do comentário e adicionando o caminho, por exemplo:

<localRepository>C:\maven-repository</localRepository>

Maven 3.2.5 - Configuração no windows 7

1. Download no link abaixo

http://archive.apache.org/dist/maven/maven-3/3.2.5/binaries/

2. Configuração da variável M2_HOME

1.   Procure o local onde o Maven foi extraído, no nosso caso foi no diretório:C:\POC\apache-maven-3.2.5
2. Acesse as “Configurações avançadas do sistema”  e, na aba Avançado, clique no botão Variáveis de Ambiente.
3. Selecione NOVO em variaveis do sistema
4. Adicione o nome m2_HOME e no valor da variável, adicione o caminho do Maven conforme imagem abaixo:

e. Após confirmar , edite variável Path que está em “Variáveis do sistema” e acrescente o caminho %M2_HOME%\bin conforme abaixo:

 

           f. Após as confirmações, teste a configuração abrindo o prompt de comando digitando mvn -version.

Veja como ficou o resultado:

Instalação jdk 1.7 no Windows 7

1. Download no link abaixo e execute a instalação

http://www.oracle.com/technetwork/pt/java/javase/downloads/jdk7-downloads-1880260.html

2. Configuração da variável JAVA_HOME

1.   Procure o local onde o JDK foi instalado, normalmente pode ser encontrado nos seguintes diretórios:

C:\Program Files\Java\jdk1.7.** 

C:\Program Files\Java\jdk… ou C:\Arquivos de Programas\Java\jdk… 

2. Acesse as “Configurações avançadas do sistema”  e, na aba Avançado, clique no botão Variáveis de Ambiente.
3. Selecione NOVO em variáveis do sistema
4. Adicione o nome JAVA_HOME e no valor da variável, adicione o caminho da instalação do JDK  conforme imagem abaixo:

5. Após confirmar , edite variável Path que está em “Variáveis do sistema” e acrescente o caminho %JAVA_HOME%\bin conforme abaixo:

6. Após as confirmações, teste a instalação  abrindo o prompt de comando digitando java -version. Veja como ficou o resultado:

How to List All Tables and Describe Tables in Oracle, MySQL, DB2 and PostgreSQL

ref:http://onewebsql.com/blog/list-all-tables

by Agnieszka Kozubek, Java Programmer at e-point SA, 22 November 2012

You often want to list all tables in a database or list columns in a table. Obviously, every database has its own syntax to list the tables and columns. Well, here it is -- all in one place for the most popular databases.

Oracle

Connect to the database:

?

1	sqlplus username/password@database-name

To list all tables owned by the current user, type:

?

1	select tablespace_name, table_name from user_tables;

To list all tables in a database:

?

1	select tablespace_name, table_name from dba_tables;

To list all tables accessible to the current user, type:

?

1	select tablespace_name, table_name from all_tables;

You can find more info about views all_tables, user_tables, and dba_tables in Oracle Documentation. To describe a table, type:

?

1	desc <table_name>

MySQL

Connect to the database:

?

1	mysql [-u username] [-h hostname] database-name

To list all databases, in the MySQL prompt type:

?

1	show databases

Then choose the right database:

?

1	use <database-name>

List all tables in the database:

?

1	show tables

Describe a table:

?

1	desc <table-name>

DB2

Connect to the database:

?

1	db2 connect to <database-name>

List all tables:

?

1	db2 list tables for all

To list all tables in selected schema, use:

?

1	db2 list tables for schema <schema-name>

To describe a table, type:

?

1	db2 describe table <table-schema.table-name>

PostgreSQL

Connect to the database:

?

1	psql [-U username] [-h hostname] database-name

To list all databases, type either one of the following:

?

1 2

\l \list

To list tables in a current database, type:

?

1

\dt

To describe a table, type:

?

1	\d <table-name>

Would you like more "cheatsheet" posts like this? Let me know in the comments!