Informacoes rapidas.

Passei por alguns problemas relacionados a codificacao de texto, String para os intimos, entao resolvi comentar sobre o assunto.

Deixarei a teoria para quem realmente entende, por exemplo: http://pt.wikipedia.org/wiki/UTF-8

Criando String UTF-8

Uma simples String codificada em formato UTF-8 é facilmente criada desta forma:

String txt = “Texto não verificado a codificacao”;

String txtUTF8 = new String(txt.getBytes(“UTF-8″));

Validando  String UTF-8

Um forma muito simples de verificar se um texto esta realmente com todos os seus caracteres em formato UTF-8 é converter o texto para UTF-8 e compara o texto resultante ao texto original.

String txt = “Texto não verificado a codificação”;

String txtUTF8 = new String(txt.getBytes(“UTF-8″));

if (!txt.equals(txtUTF8)) {

System.out.println(“Texto original nao esta em UTF-8″);

}

Validando XML UTF-8

Segue abaixo alguns endereços que podem ser utilizados para estudar para certificações Java.

SCJP

http://java.sun.com/docs/books/tutorial/extra/certification/index.html

Teste de proficiência - Java Platform

• Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 (CX-310-055)
• Sun Certified Business Component Developer for the Java Platform, Enterprise Edition 5 (CX-310-091)
• Sun Certified Mobile Application Developer for the Java 2 Platform, Micro Edition, Version 1.0 (CX-310-110)
• Sun Certified Developer for Java Web Services (CX-310-220)

Tutoriais Java

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

Quem tiver mais alguma dica pode comentar que adiciono.

Como qualquer outra linguagem, o “scripting” JSP tem uma gramática bem definida que inclui elementos de sintaxe para desenvolver diversos processos. Uma linguagem de alto nível, que também é chamada de “TAGS JSP”, classificadas em seis categorias.
Comentarei um pouco sobre cada uma dessas categorias.

Forma resumida das categorias

• Directive: Especifica o momento de tradução do JSP
• Declaration: Declara e define métodos e variáveis
• Scriplet: Permite ao desenvolvedor escrever de forma livre dentro de página JSP
• Expression: Usado para imprimir (escrever) valores no HTML de saída em uma página JSP
• Action: Prové instruções em tempo de execução para o motor JSP
• Comment: Usado para documentação e comentário do código JSP

Forma detalhada das categorias

DIRECTIVE (Diretivas)

As “directives” (diretivas) prevêem informações gerais sobre a página JSP para o motor JSP. Existem três tipos de diretivas: page, include e taglib.

• page: Informa ao motor JSP sobre as propriedades da página JSP.

Exemplo: Informar que a página JSP usará Java como linguagem de script.
<%@ page language=”java” %>

• include: Informa ao motor JSP para incluir o conteúdo de outro arquivo (HTML, JSP, etc) na página atual.

Exemplo: Informar que o conteúdo da página paginaLogin.html seja incluído dentro da página atual.
<%@ include file=”paginaLigin.html” %>

• taglib: Associa o prefixo com um tag library (biblioteca de tags).

Exemplo: Associar a biblioteca “yrosslib.tld” a página JSP
<%@ taglib prefix=”yrosstag” uri=”yrosslib.tld” %>

Observação: As diretivas SEMPRE começam com <%@ e terminam em %>
<%@ page        attribute-list %>
<%@ include     attribute-list %>
<%@ taglib      attribute-list %>

Pontos importantes sobre a sintaxe das diretivas

• Os nomes de tag, os atributos, os valores são “case sensitive” (Sensíveis a escrita)
• O valor deve ser envolvido por um par de aspas simples ou duplas
• Um par de aspas únicas é equivalente a um par de aspas simples
• Não deve existir espaço entre o sinal de (=) e o valor.

DECLARATIONS (Declarações)

Declaram e definem métodos e variáveis que podem ser utilizados dentro da página JSP.

Exemplo:

Declarar uma variável chamada contador do tipo inteira com valor inicial igual a zero.

<%! int contador = 0; %>

Esta variável será iniciada APENAS quando a página for carregada a primeira vez pelo motor JSP, o valor será mantido nas requisições subseqüentes.

Uma declaração sempre inicia com <%! e termina com %>. Ela pode conter muitas declarações java validas.

Exemplo:

<%! String nomes[] = {“Ythalo Rossy”, “Haylander”, “He-man”, “G.I. Joe”} %>

<%!

String getNome(int i) {

try {

return nomes[i];

} catch (Exception e) {

return null;

}

}

%>

No exemplo anterior a presença das duas declarações é apenas ilustrativa, para mostrar que é possível utilizar diversas declarações.

SCRIPTLETS

Scriptlets são fragmentos de código Java inserido em página JSP que são executados cada vez que são requisitadas.
Permite a inserção de regras de negocio (lógica computacional) dentro das paginas JSP.

Uma scriptlet sempre inicia com <% e termina com %>. Ela pode conter muitas linha de código Java valida.

Exemplo:

Página JSP que contabiliza a quantidade de acessos

<%@ page language=”java” %>

<%! int contador = 0;       %>

<%

out.print(“<html><body>”);

contador++;

out.print(“Bem vindo! Você é nosso visitante numero ” + contador);

out.print(“</body></html>”);

%>

Onde:

<%@ page language=”java” %>: Diretiva page que diz que usaremos Java como linguagem.

<%! int contador = 0; %>: Declaração de variável. Lembre que as declarações acontecem apenas uma vez ao carregar.

<%

out.print(“<html><body>”);

%>: A referência out, que por padrão representa um objeto do tipo javax.servlet.jsp.JspWriter, é utilizada para escreve diretamente no fluxo de dados da resposta.

Observe que é necessário seguir a sintaxe correta de declarações do Java. Utilizar o out.println(“TESTE”) sem colocar o (;) ponto e virgula no final gera um erro de compilação.

EXPRESSIONS (Expressões)

Expressions atuam como espaços reservados para expressões da linguagem Java, que são avaliadas cada vez que a página é acessada.

Tem a capacidade de escrever diretamente no HTML de saída valores primitivos, de um objeto, retorno de um método, expressões aritméticas ou booleanas.

Uma expressão sempre inicia com <%= e termina com %>.

Observações:

• Só pode existir uma expressão
• A expressão não deve ser finalizada com (;) ponto e vírgula

Exemplo:

Validas

<%= 500  %>

<%= anInt*3.5/100-500 %>

<%= aBool %>

<%= false %>

<%= !false %>

<%= getChar() %>

<%= Math.random() %>

<%= aVector %>

<%= aFloatObj %>

<%= aFloatObj.floatValue() %>

<%= aFloatObj.toString() %>

Invalidas

<%= aBool; %>

<%= int i = 20 %>

<%= sBuff.setLength(12); %>

ACTIONS (Ações)

Actions são comandos executados diretamente pelo motor JSP durante a execução da página JSP.

Os actions JSP são divididos em seis padrões, conforme segue abaixo:

• jsp:include
• jsp: forward
• jsp:useBean
• jsp:setProperty
• jsp:getProperty
• jsp:plugin

Resumindo, jsp:include e jsp:forward permitem a página JSP utilizar outro componente web, os próximos três, jsp:useBean, jsp:setproperty e jsp:getProperty, são utilizados para o uso de javaBeans dentro das página JSP. A ultima ação, jsp:plugin, instrui ao motor JSP gerar código HTML apropriado para incorporar componentes do lado do cliente, como Applets.

O desenvolvedor pode customizar suas próprias ações, conhecidas como tags customizadas. A sintaxe das ações JSP segue o seguinte padrão:

<jsp:actionName attribute-list />

Onde:

actionName: O nome de uma das seis ações padrões mencionadas (podendos ser uma tag customizada).

attribute-list: Representa uma lista de atributos pares chave=valor especificos para a ação.

Observações:

• O nome da ação, seus atributos e seus valores são sensíveis a escrita (case sensitive)
• O valor deve esta entre um par de aspas simples ou duplas
• Não pode existir espaço em branco entre o sinal de (=) e o valor.

COMMENTS (Comentários)

São utilizados para o propósito de documentação entre os desenvolvedores e não afetam a saída da página JSP. A sintaxe de um comentário JSP é a seguinte:

<%– Alguma coisa a ser comentado –%>

O comentários em JSP sempre iniciam com <%– e terminam com –%>

7º Aniversário do CEJUG

O Cejug chega aos seus sete anos de existência e entre seus diversos programas o Café com Tapioca já é um dos mais tradicionais eventos de Java e TI no Nordeste. Trazendo palestrantes nacionais e internacionais, o evento reúne e agrega a comunidade Cerense dos aficionados por Java mostrando as novidades, tendências e trabalhos de desenvolvimento do estado e do mundo.

Venha prestigiar o evento, participar, conhecer pessoas incríveis, ganhar brindes e fazer parte dessa história.

Programação

- 8h10: Credenciamento

- 8h40: Abertura

- 9h10: “O caminho da produtividade para desenvolvedores web” com Bruno Pereira

- 10h:   “Como fazer uma aplicação JEE/JME para rodar nos 4 cantos do mundo” com Régis Melo

- 11h:   “O mito dos times ágeis” com Victor Oliveira

- 12h – Intervalo para Almoço. Opções próximas: Pão de Açúcar, McDonald’s ou Subway ou um pouco mais longe: Spettus (Shopping Salinas – mapa); Ferreiro Café (Shopping Iguatemi – mapa).

- 13h30: “Os 10 maus hábitos dos desenvolvedores JSF” com Tarso Bessa e Rafael Ponte

- 14h20: “Turbinando sua aplicação com Lucene: conheça Solr e Hibernate Search” com Jeveaux

- 15h10: Lanche

- 15h20: “O que matou o RUP também pode matar o Agile” com Rodrigo Yoshima

- 16h30: “Desmistificando o TDD na prática“ com  Paulo Silveira

- 17h40 – Sorteios

Dentro da especificação Servlet existe uma parcela que compreende a segurança dos recursos acessados por cliente. Dentre estes recursos esta autenticação através de formulário, certificados digitais e ate mesmo por tela autenticação gerada pelo próprio browser.

Dividirei o conteúdo em algumas partes e logo que for terminando de compor estarei disponibilizando. Segue abaixo em negrito o conteúdo que terminei:

Parte 01: Os quatro mecanismo de autenticação

Parte 02: Implantando

Implantando mecanismos de autenticação para aplicações web

Todas as configuração de autenticação são feitas no descritor de implantação (web.xml) e são conhecidas como segurança declarativa. Por padrão todos os recursos de uma aplicação web são acessíveis por todos. Para restringir acesso aos recursos, precisamos identificar três coisas:

• Coleção de recursos web (Web resource collection): São os recursos que realmente precisam de restrições, tais como arquivos HTML, Servlets, entre outros.
• Restrição de autorização (Authorization constraint): São as regras que um usuário/cliente do recurso precisa ter para acessar.
• Restrição de dados do usuário (User data constraint): Especifica o caminho que os dados devem seguir para serem transmitidos do emissor ate o receptor. Em outras palavras, específica a camada de transporte que mantém a política de integridade dos dados e confidencialidade.

A configuração destes itens acontece no descritor de implantação (web.xml) através do elemento  <security-constraint>, que fica diretamente abaixo do elemento <web-app>.

<web-app>

…

<security-constraint>

<web-resource-collection>

<web-resource-name>relatorios</web-resource-name>

<url-pattern>/servlet/YRossRelatoriosServlet/*</url-pattern>

<url-pattern>/servlet/YRossFinanceirosServlet/*</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENCIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

<login-config>

<auth-method>CLIENT-CERT</auth-method>

</login-config>

…

</web-app>

Onde:

<web-resource-collection>: Especifica uma coleção de recursos que devem ser aplicadas restrições de segurança.

<web-resource-name>: Nome do recurso

<url-pattern>: Específica o padrão URL em que o recurso será acessado. Semelhante ao <url-pattern> do elemento <servlet-mapping> do mapeamento de URL para um servlet.

<http-method>: Provém um controle sobre requisições HTTP. Específica o método HTTP que as regras de segurança serão aplicadas.

No exemplo anterior serão aplicadas regras de segurança para todas as requisições aos servlets YRossRelatoriosServlet e YRossFinanceirosServlet, sejam elas GET ou POST.

Observação: A ausência do elemento <http-method>, fará com que todas as requisições, independente do método HTTP, sejam restringidas por regras de segurança, caso exista.

É possível observar que dentro do elemento <security-constraint> no exemplo anterior o elemento <security-constraint> é declarado informando o tipo de canal de comunição entre o cliente e servidor.

<user-data-constraint>

<transport-guarantee>CONFIDENCIAL</transport-guarantee>

</user-data-constraint>

Onde:

<transport-guarantee>: Especifica a comunicação entre o cliente e o servidor. Pode assumir os seguintes valores:

- NONE: A aplicação não requer um transporte garantido.

- INTEGRAL: A aplicação requer que os dados enviados do cliente ao servidor estejam em um caminho em que as informações não podem ser alteradas em trânsito. Princípio da Integridade.

- CONFIDENTIAL: A aplicação requer que os dados sejam transmitidos em uma forma que impede que outras entidades observem o conteúdo da transmissão. Geralmente utilizado sobre SSL.

O trecho abaixo, ainda do exemplo anterior, informa que tipo de autenticação será realizada entre o cliente e o servidor.

<login-config>

<auth-method>CLIENT-CERT</auth-method>

</login-config>

Onde:

<auth-method>: Indica qual o método de autenticação. Assume como valor: BASIC, CLIENT-CERT e FORM.

Dentro da especificação Servlet existe uma parcela que compreende a segurança dos recursos acessados por cliente. Dentre estes recursos esta autenticação através de formulário, certificados digitais e ate mesmo por tela autenticação gerada pelo próprio browser.

Dividirei o conteúdo em algumas partes e logo que for terminando de compor estarei disponibilizando. Segue abaixo em negrito o conteúdo que terminei:

Parte 01: Os quatro mecanismo de autenticação

Parte 02: Implantando

Parte 01: Os quatro mecanismo de autenticação

A especificação Servlet define quatro mecanismos de autenticação de usuários.

• HTTP Basic authentication
• HTTP Digest authentication
• HTTPS Client authentication
• HTTP FORM-based authentication

HTTP Basic Authentication

Definido na especificação HTTP 1.1 é o mais simples e mais comum mecanismo usado para proteger recursos. Onde cada vez que um recurso protegido é solicitado é o browser retorna com uma tela solicitando nome de usuário e senha.

Em resumo os seguintes passos acontecem:

• O browser/navegador envia uma requisição para um recurso protegido. Mas o browser não sabe que este recurso é protegido, ele apenas envia uma requisição normal HTTP e aguarda a resposta.

Exemplo: GET /servlet/YRossServlet HTTP/1.1

• O servidor ao receber a solicitação observa que o recurso é protegido, e ao invés de enviar o recurso, uma mensagem contendo o “code de status” igual a 401 Unauthorized é retornada de volta para o cliente (browser). Nesta mensagem, uma linha de cabeçalho é adicionada para informar ao browser que uma autenticação básica é necessária para acessar o recurso. Este cabeçalho especifica o contexto em que a autenticação será valida. Este contexto é conhecido como “realm”. Ele ajuda a organizar a lista de acesso dentro do servidor em diferentes categorias.

Exemplo:

HTTP/1.1 401 Unauthorized
Server: Tomcat/5.0.25
WWW-Authenticate: Basic realm=”administracao”
Content-Length=500
Content-Type=text/html

<html>
… dados…
</html>

Onde:

WWW-Authenticate: Basic: especifica o tipo de autenticação como Basic

realm=”administracao”: especifica o contexto (realm)

• O browser recebe esta resposta, abre uma caixa de diálogo perguntando pelo nome de usuário e senha.
• Uma vez que usuário entrou com nome de usuário e senha, o browser reenvia a requisição e passa no cabeçalho o valor “Authorization” com as informações digitadas pelo cliente.

Exemplo:

GET /servlet/SalesServlet HTTP/1.1
Authorization: Basic am9objpqamo=

Onde:

O Authorization especifica o realm como Basic e o valor “am9objpqamo=” é composição do nome de usuário e senha no seguinte formato: nomeusuario:senha, encodado na base 64 (Base64 encoded).

• Quando o servidor recebe a requisição, ela valida o nome de usuário e senha. Se eles são validos, ele envia o recurso, por outro lado, se as informações estão invalidas, o servidor envia a mesma mensagem 401 Unauthorized.
• O browser mostra o recurso (ou a caixa de dialogo novamente, solicitando nome de usuário e senha).

Vantagens

1. É muito fácil de usar.
2. Todos os browsers suportam, por ser uma especificação do HTTP 1.1

Desvantagens

1. Não é seguro porque o nome de usuário e senha não são encriptados.
2. Não é possível customizar, modificar, o visual da caixa de diálogo que solicita nome de usuário e senha.

HTTP Digest Authentication

Segue os mesmos passos do HTTP Basic authentication, mas neste caso a senha (password) é enviada em formato encriptado. Este método torna mais seguro a autenticação.

Vantagens

1. Um pouco mais seguro que HTTP Basic authentication, por ter a senha (password) encriptado.

Desvantagens

1. É suportado apenas em alguns browsers, como em versões superiores do Internet Explore 5.
2. Muitos “servlet container” não suportam, pois a especificação não obriga.

HTTPS Client Authentication

HTTPS é o HTTP sobre SSL (Secure Socket Layer).

SSL foi desenvolvido pela Netscape para assegurar a privacidade da transmissão de dados sensíveis sobre a internet. Neste mecanismo, a autenticação é feita quando uma conexão SSL e estabelecida entre o browser e o servidor. Todos os dados são transmitidos em formato encriptado utilizando criptografia de chave publica(public-key) entre o browser e o “servlet container”, fincando assim transparente para o desenvolvedor.

Vantagens

1. É o sistema de autenticação mais seguro, entre os quatro tipos especificados.
2. Todos os browsers comumente usados têm suporte.

Desvantagens

1. É necessário um certificado de uma autoridade certificadora, como VeriSign, ou ICP-Brasil.
2. É custosa a implementação e manutenção.

FORM-based Authentication

Este mecanismo é similar a autenticação básica (Basic Authentication). Entretanto, neste é utilizado um formulário  HTML para captura o nome usuário e senha (username/password). O desenvolvedor deve criar uma página HTML contendo o formulário, que permite a customização do visual.

O unico requerimento é que a ação do formulário seja j_security_check e que deve ter dois campos: j_username e i_password.

Vantagens

1. É muito fácil de implementar
2. Todos os browsers suportam
3. É possível a customização da tela de autenticação.

Desvantagens

1. Não é seguro, o nome de usuário e senha não são encriptados.
2. Deve ser usado apenas quando uma sessão é mantida usando cookies ou HTTPS

Implantando

Em Breve…

Tecnicamente falando, filtro é um objeto que intercepta uma mensagem de requisição entre a origem/cliente e destino/recurso.

Como funciona?

Associando a origem ao browser/navegador, o destino a um servlet e uma implementação de HttpServletRequest a mensagem de requisiçao é possível interceptar estas requisições através de um filtro.

A mensagem antes de chegar ao servlet é recepcionada/interceptada por um filtro que aplica alguma regra de negocio da aplicação e permite ou não o acesso ao servlet. Caso o acesso seja concebido a mensagem chegará ate o servlet e será processada, ao terminar o processo o servlet responde (HttpServletResponse), a resposta passará novamente pelo filtro antes de chegar ao cliente/origem.

Exemplo de Filtro Simples

Encadeando

É possível encadear vários filtros, por exemplo, supondo que é necessário verificar se um cliente esta autenticado (AutenticadoFiltro) e se tem permissão (PermissãoFiltro) para acessar determinado recurso. Desta forma ao acessar o recurso o filtro AutenticadoFiltro é executado, logo em seguida o PermisãoFiltro é executado, caso o acesso seja concebido o recurso é acessado e processado, quando uma resposta estiver voltando para o cliente, os filtros serão acessados de forma contraria, desta vez o PermisãoFiltro será executado primeiro e logo em seguinda o AunteticadoFiltro.

Exemplo de Filtro Encadeado

Filtros podem ser utilizados para diversas funcionalidades, tais como: Autenticação, Log, conversão de imagens, compressão de dados, criptografia, dentre outros.

Filtro em ação

import java.io.*;
import javax.servlet.*;

public class YRossFilter implements Filter {

private FilterConfig filterConfig;

public void init(FilterConfig filterConfig){

this.filterConfig = filterConfig;

}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

throws ServletException, IOException {

PrintWriter pw = response.getWriter();

pw.println(“<html>”);

pw.println(“<head>”);

pw.println(“</head>”);

pw.println(“<body>”);

pw.println(“<h3>YRoss Filter!</h3>”);

pw.println(“</body>”);

pw.println(“</html>”);

pw.flush();

}

public void destroy() { }

}

No exemplo anterior o filtro apenas retorna uma mensagem para o browser/origem utilizando o ServletResponse. É importante resaltar

Implantando o Filtro

É necessário algumas tags no descritor de implantação (web.xml) para que os filtros possam interagir com as requisições e respostas. Segue como deve ficar as tags:

<web-app>

…

<filter>

<filter-name>YRossFilter</filter-name>

<filter-class>br.com.yross.filters.YRossFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>YRossFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

…

</web-app>

Onde:

<filter>: Tag que define o filtro.

<filter-name>: Nome representativo para o filtro.

<filter-class>: Classe que implementa a interface javax.servlet.Filter.

<filter-mapping>: Tag que define os mapeamentos para as requisições que devem passar pelo filtro.

<filter-name>: Nome representativo do filtro que deve interceptar a requisição.

<url-pattern>: URI que será filtrada.

Uma observação deve ser feita aqui, o <filter-mapping> pode ser utilizado para mapear todas as requisições para um determinado servlet, para isso é necessário a utilização da tag <servlet-name>. Se usado em conjunto com <url-pattern>, a tag <url-mapping> terá prioridade sobre a <servlet-name>.

Algumas observações

- Existe apenas um filtro para cada tag <filter> no descritor de implantação (web.xml), por maquina virtual.

- É possível encaminhar e incluir recursos utilizando RequestDispatcher.forward() e RequestDispatcher.include(), respectivamente.

- Retorna páginas de erro.

- Pontos de execução são controlados dentro do mapeamento de filtros dentro do web.xml, como segue abaixo:

<filter-mapping>

<filter-name>YRossFilter</filter-name>

<url-pattern>/*</url-pattern>

<dispatcher>REQUEST</dispatcher>

<dispatcher>FORWARD</dispatcher>

<dispatcher>INCLUDE</dispatcher>

<dispatcher>ERROR</dispatcher>

</filter-mapping>

Neste exemplo os pontos de ação dos filtros serão as requisições (REQUEST), encaminhamentos (FORWARD), includes (INCLUDE) ou páginas de erro (ERROR). Se nenhum ponto de ação for especificado o REQUEST será o padrão.

Conhecemos formas de adicionar atributos em uma javax.servlet.http.HttpSession, em um javax.servlet.ServletContext e ate mesmo em javax.servlet.HttpServletRequest, também sabemos que javax.servlet.ServletContext e javax.servlet.http.HttpSession são inicializados e destruidos para dar suporte ao compartilhamento de dados. Mas como interagir com esses eventos?

Bem, a resposta é simples, dentro da própria API Servlet é possível encontrar algumas interfaces que quando implementadas são capazes de responderem a esta pergunta.

Eventos relacionados manipulação de atributos

A manipulação de eventos relacionados a atributos são ouvidos pelas seguintes interfaces:

• HttpSessionAttributeListener: Eventos relacionados a HttpSession
• ServletContextAttributeListener: Eventos relacionados ao ServletContext
• ServletRequestAttributeListener: Eventos relacionados ao ServletRequest

Para cada interface é necessário implementar três métodos, com uma assinatura padrão, mudando apenas o parametro recebido no método, que deve ser filho de javax.servlet.http.HttpSessionEvent.

HttpSessionAttributeListener

• public void attributeRemoved(HttpSessionBindingEvent bindingEvent)
• public void attributeReplaced(HttpSessionBindingEvent bindingEvent)
• public void attributeAdded(HttpSessionBindingEvent bindingEvent)

ServletRequestAttributeListener

• public void attributeAdded(ServletRequestAttributeEvent attributeEvent)
• public void attributeRemoved(ServletRequestAttributeEvent attributeEvent)
• public void attributeReplaced(ServletRequestAttributeEvent attributeEvent);

ServletContextAttributeListener

• public void attributeAdded(ServletContextAttributeEvent attributeEvent)
• public void attributeReplaced(ServletContextAttributeEvent attributeEvent)
• public void attributeRemoved(ServletContextAttributeEvent attributeEvent);

Eventos relacionados a criação e destruição

ServletContext

Permite ao desenvolvedor saber quando o contexto foi inicializado ou destruido. A interface javax.servlet.ServletContextListener deve ser implementada. Esta interface define dois métodos:

• public void contextInitialized(ServletContextEvent contextEvent):  Sempre que o contexto foi inicializado.
• public void contextDestroyed(ServletContextEvent contextEvent): Sempre que o contexto for destruído.

Uma utilização comum para o uso desta interface é a criação ou instanciação de recursos, como conexões a banco de dados, que devem ser destruída, quando o contexto for destruído.

HttpSession

Permite ao desenvolver saber quando uma sessão foi inicializada ou destruida. A interface javax.servlet.Http.HttpSessionListener deve ser implementada. Esta interface define dois método:

• public void sessionCreated(HttpSessionEvent sessionEvent): Sempre que uma sessão é criada.
• public viod sessionDestroyed(HttpSessionEvent sessionEvent): Sempre que uma sessão é destruida.

HttpServletRequest

Permite ao desenvolvedor saber quando uma requisição é efetuada do cliente ao escopo do servlet. A interface javax.servlet.Http.HttpServletRequestListener deve ser implementada. Esta interface define dois métodos:

• public void requestInitialized(ServletRequestEvent requestEvent): Sempre que uma requisição é feita
• public void requestDestroyed(ServletRequestEvent requestEvent): Sempre que uma requisição é atendida

Definindo o uso de listener(Ouvintes)

Em alguns passos definirei o que é necessário para criar um listerner(ouvinte) dos eventos.

Passo 1:  Criar uma classe que implemente um ou mais interfaces

public class YRossAttibuteListener implements HttpSessionAttributeListener {

…

}

Passo 2: Implementar os métodos das interfaces.

public class YRossAttibuteListener implements HttpSessionAttributeListener {

public void attributeAdded(HttpSessionBindingEvent bindingEvent) {

println(“Adicionado Atributo Session”);

}

public void attributeRemoved(HttpSessionBindingEvent bindingEvent) {

println(“Removido Atributo Session”);

}

public void attributeReplaced(HttpSessionBindingEvent bindingEvent) {

println(“Modificado Atributo Session”);

}

}

Passo 3: Definir que esta classe é um listener no descritor de implantação (web.xml), como segue abaixo:

<web-app>

<listener>

<listener-class>br.com.yross.listeners.YRossAttibuteListener</listener-class>

</listener>

<listener>

<listener-class>br.com.yross.listeners.YRossServletContextListener</listener-class>

</listener>

</web-app>

Ufa, terminou, mas existem diversas interfaces que podem ser utilizadas para ouvir os eventos. Vale a pena pesquisa um pouco mais.

Tagged: event, HttpSessionAttributeListener, JEE, Servlet, ServletContextAttributeListener, ServletContextListener, ServletRequestAttributeListener ]]> http://yross.wordpress.com/2009/07/22/eventos-e-seus-ouvintes-listeners-em-servlets/feed/ 0 yross http://yross.wordpress.com/2009/07/22/servletconfig-x-servletcontext/ http://yross.wordpress.com/2009/07/22/servletconfig-x-servletcontext/#comments Wed, 22 Jul 2009 14:29:01 +0000 Ythalo Rossy http://yross.wordpress.com/?p=107 ]]>

Pretendo discutir um pouco sobre o uso de ServletConfig e ServletCOntext, existem pequenas diferenças entre os dois, mas especificamente no contexto de acesso as informaçoes contidas nos dois.

ServletConfig

A interface javax.servlet.ServletConfig prove diversas informações sobre o servlet atual, tais como parâmetros de inicialização e nome do servlet, esta diretamente ligada ao servlet e não tem informações de outros servlets.

Um exemplo de utilização desta interface seria a busca de parâmetros de inicialização dentro do método init() do servlet.

Defino um parâmetro de inicialização para o servlet:

<servlet>

<servlet-name>TestServlet</servlet-name>

<servlet-class>br.com.yross.servlets.TestServlet</servlet-class>

<init-param>

<param-name>nameParamInitServlet</param-name>

<param-value>valueParamInitServlet</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

Busco esta informações na inicialização do servlet, para isso reescrevo o método init():

public class YRossServlet extends HttpServlet {

public void init() throws ServletException {

String valueParamInitServlet = getServletConfig().getInitParameter(“nameParamInitServlet”);

System.out.println(“ServletConfig – valueParamInitServlet: ” + valueParamInitServlet);

}

}

Observe o uso do método getServletConfig() implementado na classe abstrata javax.servlet.GenericServlet, ele retorna um objeto javax.servlet.ServletConfig com todas as configurações necessárias para a existência do servlet atual. Em resumo a o ServletConfig contém apenas informações do servlet que esta atendendo a requisição, diferente do ServletContext que contém informações compartilhadas no contexto dos servlets.

ServletContext

Um pouco diferente do ServletConfig, a interface javax.servlet.ServletContext tem a capacidade de armazenar informações que podem ser compartilhadas entre todos os servlet no contêiner servlet, tais como informações de conexão com um determinado banco de dados, estas informações podem ser compartilhadas com diversos servlet que precisam de acesso ao banco de dados, exemplo:

<web-app>

…

<context-param>

<description></description>

<param-name>dburl</param-name>

<param-value>jdbc:databaseurl</param-value>

</context-param>

…

</web-app>

Observe que o parâmetro não é informado para um servlet específico, mas para o contexto dos servlet dentro do contêiner.

Reutilizando o exemplo anterior, recupero as informações de a maneira a seguir:

public class YRossServlet extends HttpServlet {

public void init() throws ServletException {

ServletContext context = getServletContext();

String dburl = context.getInitParameter(“dburl”);

System.out.println(“ServletContext – Url para base de dados: ” + dburl);

}

}

Observe o uso do método getServletContext() implementado na classe abstrata javax.servlet.GenericServlet, ele retorna um objeto javax.servlet.ServletContext com todas as informações de contexto dos servlets.

É possível conseguir uma instancia de ServletContext atraves do ServletConfig, exemplo:

ServletContext context = getServletConfig().getServletContext();

A API Servlet inclui a interface javax.servlet.RequestDispatcher com a finalidade de encaminhar a requisição atual para outro recurso, como um outro servlet.

Exemplo:

Um usuário solicita o histórico das compras do mês, ao receber a requisição o Servlet (HistoricoServlet)  verifica que o usuário não esta logado no sistema, o HistoricoServlet então encaminhar a requisição para outro servlet, chamado LoginServlet, que tem a finalidade de gerar o formulário de autenticação.

A interface javax.servlet.RequestDispatcher possui dois métodos que permitem esta interação, são:

• void forward (ServletRequest request, ServletResponse response): Permite o servlet processar a requisição parcialmente e encaminhar a requisição para outro servlet para gerar a resposta final. Também pode ser usado para encaminhar a requisição para recursos como JSP ou HTML. Se for chamado depois que a resposta estiver sido comitada será lançada uma IllegalStateException.
• void include (ServletRequest request, ServletResponse response): Permite que o conteudo de outro recurso processe temporariamente a requisição atual. O recurso incluido não pode setar headers (cabeçalhos) ou status code (código de estatus) para a resposta, tentativas de setar serão ignoradas.

Parece uma boa solução, mas como conseguir um RequestDispatcher? Simples: Ambos javax.servlet.ServletContext e javax.servlet.ServletRequest possuem o método public RequestDispatcher getRequestDispatcher(String path) que pode ser utilizado para recuperá-lo.

Existe uma pequena diferença em usar o getRequestDispatcher no ServletContext e no ServletRequest. No ServletContext não é possível utilizar o caminho relativo para um recurso, o caminho deve iniciar com “/”. No ServletRequest é possível utilizar caminhos relativos, por exemplo ServletRequest.getRequestDispatcher(../paginas/index.html).

Tagged: JEE, RequestDispatcher, resquest, Servlet ]]> http://yross.wordpress.com/2009/07/21/requestdispatcher/feed/ 0 yross