Criar um pool de conexões no Apache Tomcat

Fonte: http://www.antoniopassos.pro.br/blog/?p=88

1)Configurando o pool de conexões…

No diretório META-INF da aplicação, crie um arquivo “context.xml” com o seguinte conteúdo…

<?xml version=”1.0″ encoding=”UTF-8″?>
<Context auth=”Container”>
<Resource
name=”jdbc/bd_teste”
type=”javax.sql.DataSource”
url=”jdbc:mckoi://localhost:59999/”
driverClassName=”com.mckoi.JDBCDriver”
username=”admin”
password=”123456″
maxActive=”100″
maxIdle=”20″/>
</Context>

Significado de cada atributo usado no arquivo “context.xml“…

  • auth –> Atribui ao Apache Tomcat a responsabilidade de gerenciar a abertura e o fechamento das conexões
  • name –> Nome dado ao pool de conexões. Deve obedecer o formato JNDIATENÇÃO: O NOME DADO AO POOL DEVERÁ SER O MESMO USADO NO ARQUIVO WEB.XML DA APLICAÇÃO.
  • type –> Especifica o tipo como sendo DataSource
  • url –> Especifica a localização do banco de dados. Deve obedecer o formato URL JDBC
  • driverClassName –> Nome da classe do driver JDBC do banco de dados
  • username –> Nome do usuário do BD
  • password –> Senha do usuário do BD
  • maxActive –> Número máximo de conexões ativas no pool
  • maxIdle –> Número máximo de conexões inativas no pool
  • maxWait –> Tempo máximo de espera por uma conexão, em milissegundos

2)Registrando o pool no aplicativo…

No arquivo “web.xml” da aplicação, insira as linhas abaixo…

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

ATENÇÃO: O valor em “<res-ref-name>” deve corresponder ao nome dado ao pool de conexões no arquivo “context.xml”. No caso a “jdbc/bd_teste”.

3)Testando o pool..

3.1) Crie uma classe “ServiceLocator.java” com o seguinte conteúdo…

import java.sql.Connection;
import javax.naming.InitialContext;
import javax.sql.DataSource;

public class ServiceLocator {

public static Connection getConexao(String JNDINome) throws Exception {
Connection con = null;

// Obtém a raiz da hierarquia de nomes
InitialContext contexto = new InitialContext();

// Obtém a origem dos dados
DataSource ds = (DataSource)contexto.lookup(“java:comp/env/” + JNDINome);

// Obtém uma conexão
con = ds.getConnection();

// Retorna a conexão
return con;
}
}

3.2) Crie um servlet, que use a classe ServiceLocator acima para obter uma conexão do pool…

import java.io.IOException;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletExemplo extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {

private static final String JNDINome = “jdbc/bd_teste”;

public ServletExemplo() {
super();
}

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType(“text/html”);
PrintWriter out = response.getWriter();
out.println(“<h1>Filmes cadastrados</h1>”);

Connection con = null;
try {
con = ServiceLocator.getConexao(JNDINome);
} catch (Exception e) {
e.printStackTrace();
}

String sql = “SELECT * FROM filmes”;
PreparedStatement stmt;
try {
stmt = con.prepareStatement(sql);
ResultSet rs = stmt.executeQuery();
while (rs.next()){
out.println(“Código -> ” + rs.getInt(1) + ” Título -> ” + rs.getString(2));
}
} catch (SQLException e) {
e.printStackTrace();
}
}

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
doGet(request, response);
}
}

<!–
google_ad_client = “pub-9909948656853681”;
google_ad_output = “textlink”;
google_ad_format = “ref_text”;
google_cpa_choice = “CAAQmbj2_gEaCNYZLJsrWhfIKL264YcBMAA”;
google_ad_channel = “9871635485”;
//–>

Gerador de senha em PHP

Fonte: http://mrsantos76.wordpress.com/

Pessoal esse script originalmente não foi eu que escrevi, vi ele uma vez na web, sinceramente não lembro onde
apenas modifiquei ele pra atender minhas necessidades e acertei um detalhe que tinha no ultimo if…
segue o cara…


///////////////////////////////////////
//
// Gerador de senha:
// uso: gerador_senha("L N L N L N")
// sendo que cada  L é uma letra
// e cada N é um numero
// nessa caso teriamos algo como k3j4j5
//
///////////////////////////////////////
function gerador_senha($tipo="L L N N")
{
    $tipo = explode(' ', $tipo);
    $padrao_letras = 'a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|x|w|y|z';
    $padrao_numeros = '0|1|2|3|4|5|6|7|8|9';
    $array_letras = explode('|', $padrao_letras);
    $array_numeros = explode('|', $padrao_numeros);
    $senha = "";
    for ($i=0; $i < count($tipo); $i++)
   {
        if ($tipo[$i] == ‘L’)
       {
             $senha .= $array_letras[array_rand($array_letras,1)];
        }
        else
       {
           $senha .= $array_numeros[array_rand($array_numeros,1)];
       }
    }
     return $senha;
}

Entendendo o serialVersionUID

Por Paulo Silveira em 01/04/2008 –

Fonte: http://blog.caelum.com.br/2008/04/01/entendendo-o-serialversionuid/

O serialVersionUID é uma dúvida constante entre muitos desenvolvedores. Afinal, quando e para que exatamente usá-lo? Devo gerar um número aleatório bem grande, ou um número qualquer? Essas perguntas são comuns, e ao desenvolvedor experiente é necessário conhecer a fundo esse detalhe do processo de serialização do Java.

Quando um objeto é serializado no Java, essa sequência de bytes, além de conter seus atributos de instância não transientes, carrega consigo um número que indentifica a “versão” da classe que foi usada durante o processo. Esse é o chamado serialVersionUID, ou seja, o indentificador de versão de serialização de uma classe. Esse número é utilizado para saber se o objeto que estamos recuperando é de uma versão “compatível” com a versão da classe que foi utilizada quando serializamos o objeto: em outras palavras, os arquivos .class não precisam ser necessariamente os mesmos para que o processo de serialização ocorra com sucesso.

Por exemplo, considere a seguinte classe Usuario:

package br.com.caelum;

public class Usuario implements Serializable {
  private String login;
}

Essa classe possui o serialVersionUID igual a 2806421523585360625L. Esse número não é aleatório! Ele é um hash (SHA) calculado em cima dos nomes dos seus atributos, e assinaturas dos métodos em uma ordem bem definida pela especificação do processo de serialização. E como eu sei esse número? O JDK vem com a ferramenta serialver, que implementa esse mesmo hash:

serialver br.com.caelum.Usuario

Se o serialVersionUID utilizado durante a serialização não bater exatamente com o serialVersionUID da classe que está sendo usada para recuperar essa informação, uma exception é lançada: java.io.InvalidClassException.

Por exemplo, se adicionarmos um novo atributo na nossa classe Usuario:

public class Usuario implements Serializable {
  private String login;
  private String senha;
}

Agora teremos o serialVersionUID valendo 416295346730660862L. Caso você serialize um Usuario com a primeira classe aqui definida, e tentar recuperar essa informação usando essa nova versão de classe, receberemos a conhecida java.io.InvalidClassException. Esse é o comportamente que em muitos casos queremos, mas algumas vezes fazemos pequenas modificações na classe as quais percebemos que não impactarão no processo de serialização, e precisamos manter compatibilidade com a versão antiga daquela classe. Para isso, basta definirmos explicitamente qual é o nosso serialVersionUID, e no caso de querer manter compatibilidade com a classe Usuario anterior, vamos utilizar o valor de serialVersionUID que seria gerado pela JVM: 2806421523585360625L. O código ficaria:

public class Usuario implements Serializable {
  private static final long serialVersionUID = 2806421523585360625L;
  private String login;
  private String senha;
}

Às vezes recebemos um warning do Eclipse, e ele pede para que seja definido o serialVersionUID da classe em questão. Isso ocorre porque você implementa Serializable ou uma de suas mães a implementa. O Eclipse então te abre três opções: utilizar o @SurpressWarnings para você assumir o risco, usar um valor default, ou usar o valor gerado. O gerador de UIDs do Eclipse é exatamente o mesmo gerador utilizado pelo Java SE para criar os UIDs padrão! Reforçando, esse número não é um número aleatório!

serialVersionUIDQuando alguém esquece de manter o mesmo serialVersionUID para duas versões compatíveis de uma classe, podemos ter problemas em usar diferentes versões do software que são teoricamente compatíveis. Isso muitas vezes acontece em servidores de aplicação, e se seu cliente esta desatualizado em relação a versão dos jars necessários pelo servidor, podemos ter alguns InvalidClassExceptions que poderiam ser facilmente evitados se o serialVersionUID tivesse sido corretamente aplicado. Claro que algumas outras vezes as versões realmente não são compatíveis e a exception procede.

Esse grave problema pode acontecer mesmo usando classes do Java SE entre diferentes versões, como é o caso da classe java.text.AttributedCharacterIterator.Attribute (utilizada pela java.awt.Font). Do Java 1.3 para o Java 1.4 essa classe foi levemente alterada, e o serialVersionUID gerado pelo algoritmo da JVM desta classe mudou de -1514471214376796190L para -9142742483513960612L. Quando alguém serializava uma java.awt.Font em uma versão não podia desserializa-la em outra, sendo que as versões tecnicamente são compatíveis: a não definição explícita do serialVersionUID gerou um bug no Java SE. Como isto foi resolvido? Definiram o serialVersionUID como -1514471214376796190L, que é o valor que seria gerado pela JVM na versão anterior da classe.

Como então devemos proceder para escolher um serialVersionUID apropriado? É muito simples: se essa classe está nascendo neste momento, você pode se dar ao luxo de utilizar um serialVersionUID, como por exemplo:

public class Usuario implements Serializable {
  private static final serialVersionUID = 1L;
  private String login;
}

Porém se você está definindo o serialVersionUID de uma classe já em produção, e sabe que a mudança que está fazendo é compatível com a versão anterior, você deve utilizar o serialVersionUID que seria gerado pela JVM na primeira versão, como foi o caso aqui quando adicionamos o atributo senha na classe Usuario, e também foi o caso da correção do bug da classe java.text.AttributedCharacterIterator.Attribute. Quando você fizer uma alteração onde percebe que o cliente precisará de atualização das classes envolvidas, basta definir um serialVersionUID diferente dos anteriormente utilizados.

Para completar, implementar uma interface que não define métodos (Serializable) e ser forçado a escrever um atributo sem um contrato mais burocrático é um tanto estranho em uma linguagem como o Java. Sem dúvida, se esse mecanismo todo tivesse sido inventado já com a existência de anotações, Serializable seria uma anotação e version um atributo dela, talvez obrigatório, criando algo como @Serializable(version=12345L). Boas serializações e invocações remotas!