Resumo Anotações SCWCD 5.0

Resumo Anotações para Certificação SCWCD 5.0

Gilberto Augusto Holms
@gibaholms
gibaholms85@gmail.com
http://gibaholms.wordpress.com/

Capítulo 1

- GET: conteúdo vai na URL, tem comprimento limitado
- POST: conteúdo vai no corpo da solicitação, não há limitações

Capítulo 2

- MVC: Model View Controller
Model: POJO
View: JSP
Controller: Servlet
- Container: gerencia o ciclo de vida dos servlets, suporte a multithread, segurança e suporte a JSP, cria os
objetos request e response, chama o método service()

Capítulo 3

- Estrutura de distribuição:
ROOT DA APLICAÇÃO
|-- WEB-INF
|-- web.xml
|-- lib
|-- classes

Capítulo 4

- Há apenas uma instância de cada servlet carregada, porém uma nova thread por solicitação
- O servlet carrega ou na hora de rodar o servidor ou quando a primeira solicitação chega, e permanece
carregado até finalizar o servidor, apenas gerenciando threads

<servlet>
<servlet-name>nome</servlet-name>
<servlet-class>br.com.MinhaClasseServlet</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/teste.do</url-pattern>
</servlet-mapping>

- Ciclo de Vida – Container:
. Carrega a classe do servlet
. Cria uma instância dela (o construtor default roda)
. Chama o método init() (é chamado apenas uma vez)
. A cada solicitação: cria uma nova thread, chama o método service(), que chama doPost() ou doGet()
. Chama o método destroy() e descarrega da memória (vira null)

- O método service() sempre tem sua própria pilha (está em uma thread separada)
- Nunca colocar códigos no construtor, pois ele ainda não é um servlet. Se precisar, colocar no método init()
- ServletConfig:
Um por servlet
Usado para acessar o ServletContext
Informações de distribuição
Parametros configurados no DD

Gilberto Holms http://gibaholms.wordpress.com/

- ServletContext:
Um por aplicação
Informações da aplicação (também no DD)
Usado para armazenar atributos que outras partes da aplicação possam acessar
Pode obter informações do servidor e do container

- Hierarquia das classes (pg 65 – servlet, pg 70 – request, pg 83 – response)
javax.servlet.Servlet (<<interface>>)
|-- javax.servlet.GenericServlet (<<abstract>>)
|-- javax.servlet.http.HttpServlet (<<abstract>>)

javax.servlet.ServletRequest (<<interface>>)
|-- javax.servlet.http.HttpServletRequest (<<interface>>)

javax.servlet.ServletResponse (<<interface>>)
|-- javax.servlet.http.HttpServletResponse (<<interface>>)

- Métodos HTTP:
GET – para obter um recurso
POST – para postar uma informação no servidor
HEAD – para obter apenas o cabeçalho
TRACE – para receber de volta o que enviou (loopback)
PUT – para colocar a informação anexada na URL requisitada
DELETE – apagar um recurso
OPTIONS – solicita uma lista dos métodos http que o servidor pode responder
CONNECT – diz para conectar no caso de tunneling
- Não existe apenas o doConnect()
- Especificação http: apenas o POST é NÃO-IDEMPOTENTE
- Idempotente: é bom, significa que pode ser chamado repetidamente sem efeitos-colaterais ao servidor
- Nos formulários html, o padrão é GET
- Request:
getParameter(String): String
getParameterValues(String): String[]
getParameterNames(): String[]
getHeader(String): String
getIntHeader(String): int
getCookies(): Cookie[]
getSession(): HttpSession
getInputStream(): ServletInputStream

getRemotePort() – porta do cliente
getServerPort() – porta para qual a solicitação foi enviada (servidor)
getLocalPort()– porta na qual a solicitação foi parar (container)

- Response:
getWritter(): PrintWritter – tem os métodos print e println (manipula caracteres)
getOutputStream(): ServletOutputStream – tem o método write (manipula bytes)
getResourceAsStream(String): InputStream
setContentType(String)

setHeader(String, String) – se não existir, adiciona; se existir, substitui
addHeader(String, String) – se não existir, adiciona; se existir, adiciona outro
setIntHeader(String, int)

- Redirecionamento:
response.sendRedirect(String)
. Redireciona para outra URL
. Aceita URL completa ou URL relativa (com ou sem barra inicial “/”)
. Cuidado: é uma String, não um objeto URL
. Volta para o browser, ou seja, o browser que trabalha (aparece na barra do navegador)
. Não pode escrever nada na resposta antes de redirecionar

RequestDispatcher view = request.getRequestDispatcher(“resultado.jsp”);


view.forward(request, response);
. Redireciona para outro servlet
. O servidor faz o trabalho (a barra do navegador não muda)

Capítulo 5

- No construtor do servlet ainda não existe objeto ServletConfig
- O container chama o método init(ServletConfig), que por sua vez chama o init(), este que deve ser sobrescrito
- Parametros de Inicialização
ServletConfig – um por servlet – método getServletConfig():
getInitParameterNames()
getInitParameter(String)

<servlet>
.......
<init-param>
<param-name>nome</param-name>
<param-value>valor</param-value>
</init-param>
</servlet>

ServletConext – um para toda a aplicação – métodos getServletContext() ou
getServletConfig().getServletContext()
getInitParameterNames()
getInitParameter(String)

<context-param>
</context-param>

Listener Evento Métodos
contextInitialized
ServletContextListener ServletContextEvent
contextDestroyed
attributeAdded
ServletContextAttributeListener ServletContextAttributeEvent attributeReplaced
attributeRemoved
requestInitialized
ServletRequestListener ServletRequestEvent
requestDestroyed
attributeAdded
ServletRequestAttributeListener ServletRequestAttributeEvent attributeReplaced
attributeRemoved
sessionCreated
HttpSessionListener HttpSessionEvent
sessionDestroyed
attributeAdded
HttpSessionAttributeListener HttpSessionBindingEvent attributeReplaced
attributeRemoved
sessionDidActivate
HttpSessionActivationListener HttpSessionEvent
sessionWillPassivate
valueBound
HttpSessionBindingListener HttpSessionBindingEvent
valueUnbound

. Apenas o HttpSessionBindingListener não precisa ser declarado no D.D. (é implementado na própria
classe que será o atributo)
. O HttpSessionActivationListener precisa ser declarado no D.D., mas pode ser implementado tanto
sozinho como na própria classe que será atributo
. No caso de attributeReplaced, o método getValue() retorna o valor antigo

- Atributos (todos possuem get, set, remove e getAttributeNames):
ServletContext – não é thread-safe


HttpSession – não é thread-safe
HttpServletRequest – é thread-safe
- Sincronização para deixar thread-safe:
. Nunca usar SingleThreadModel
. Melhor opção:
synchronized ( getServletContext() ) { //codigo thread-safe }
synchronized ( request.getSession() ) { //codigo thread-safe }
- Request Dispatching
. Possui os métodos forward e include
. Obter o objeto RequestDispatcher através do ServletRequest:
request.getRequestDispatcher(String)
//Cuidado: com barra é da raiz, sem barra é relativo
. Obter o objeto RequestDispatcher através do ServletContext:
getServletContext.getRequestDispatcher(String)
//Cuidado: APENAS com barra (não existe relativo sem barra

- Cuidado: IllegalStateException – ocorre quando dispacha depois de escrever na saída

Capítulo 6

- Sessões
. Objeto HttpSession
. Utiliza um cookie chamado jsessionid
. O cliente precisa sempre retornar o jsessionid
. Se o browser cliente tiver desabilitado cookies, precisa utilizar reescrita de url:
Na mão: adicionar “;jsessionid=892364928469” no final de cada url
Automático no Servlet: response.encodeURL(“/teste.do”)
Automático no JSP: utilizar tag JSTL <c:URL>
Automático ao redirecionar: response.encodeRedirectURL(“/teste.do”)
. request.getSession() ou request.getSession(true) – se existir, retorna ela, senão, cria uma nova e
retorna ela
. request.getSession(false) – se existir, retorna ela, senão, retorna null
. Os eventos dos listeners de sessão também possuem os getSession
. Métodos do objeto HttpSession:
isNew() – informa se a sessão é nova (ainda não veio do cliente)
getCreationTime() – retorna um long da data de criação
getLastAccessesTime() – retorna um longda data de ultimo acesso
setMaxInactiveInterval(long seconds) – seta o timeout (em SEGUNDOS)
getMaxInactiveInterval() – retorna o timeout (em segundos)
invalidate() – encerra a sessão (depois disso, operações resultam IllegalStateException)
. Setando timeout pelo D.D. (aqui é em MINUTOS):
<session-config>
<session-timeout>15</session-timeout>
</session-config>
. Aplicações distribuídas
- mais de uma VM
- apenas a sessão migra, os outros objetos são duplicados
- apenas atributos serializáveis podem manter seu estado
- invoca o HttpSessionActivationListener (o próprio objeto implementa, porém precisa estar
declarado no D.D.)

. Enviando Cookies
Cookie cookie = new Cookie(“username”, name);
Cookie.setMaxAge(30*60); //SEGUNDOS
response.addCookie(cookie);
. Recebendo Cookies
Cookie[] cookies = new request.getCookies();
for ( int i = 0 ; i < cookies.length ; i++) {
Cookie cookie = cookies[i];
if ( cookie.getName().equals(“username”) ) {
String name = cookie.getValue();
break;
}


}
. Cuidado: não existe método getCookie(String), não existe setCookie, não existe
response.addCookie(“username”, name);

Capítulo 7

- Ciclo de Vida do JSP – idêntico ao do servlet, disponibiliza os métodos:
jspInit() – é chamado pelo init() do servlet, tem acesso ao ServletConfig e ServletContext
jspDestroy() – é chamado pelo destroy() do servlet
_jspService() – é chamado pelo service do servlet, não pode sobrescrever, nele vai todo o código dos
scriptlets do JSP (cuidado com o underline)
- Cuidado: <%@ %> e <%= %> não possuem ponto-e-virgula
- As declarações <%! %> viram variáveis de instância ou métodos no servlet
-  comentário HTML, <%-- --%> comentário JSP (não aparece)
- Objetos implícitos:

Objeto Tipo Observações
É um PrintWriter com mais
out JspWriter
funcionalidades
request HttpServletRequest
response HttpServletResponse
session HttpSession
application ServletContext
config ServletConfig
Encapsula chamadas para os
pageContext PageContext
outros objetos implícitos
page Object
exception JspException Apenas para páginas de erro

- Parâmetros de inicialização do JSP (parecido com do servlet):
<servlet>
.......
<jsp-file>/Teste.jsp</jsp-file>
<init-param>
</init-param>
</servlet>

- Escopos de atributos:

Escopo No JSP No Servlet (lembrete)
Application application.getAttribute(“nome”) getServletContext.getAttribute(“nome”)
Session session.getAttribute(“nome”) request.getSession.getAttribute(“nome”)
Request request.getAttribute(“nome”) request.getAttribute(“nome”)
Page pageContext.getAttribute(“nome”)

- Objeto PageContext (extende JspContext)
getAttribute(String) – acessa apenas o escopo Page
getAttribute(String, int escopo)
getAttributeNamesInScope(int escopo)
findAttribute(String) – acessa todos os escopos, do restrito ao abrangente

. Constantes int de escopo:
APPLICATION_SCOPE
SESSION_SCOPE
REQUEST_SCOPE
PAGE_SCOPE

. Outros métodos:
getServletContext()
getServletConfig()

getRequest()
getSession()

- Diretiva <%@ page %>
import
isThreadSafe – define se o servlet gerado precisa implementer SingleThreadModel – RUIM
contentType – define o MIME-TYPE
isELIgnored – ignora expression language
errorPage – define o URL da página de erro, onde o servlet lançará as exceptions
isErrorPage – fala que esta é uma página de erro que receberá exceptions (permite acesso ao objeto
implícito exception)

- Diretiva <%@ taglib tagdir = “/WEB-INF/tags/cool” prefix = “cool” %>

- Diretiva <%@ include file = “teste.html” %>

- Outras configurações JSPs no D.D.
. Desabilitar SCRIPTLETS na página (obs: não pode desabilitar no próprio JSP)

<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>

. Desabilitar EL na página (obs: pode desabilitar no próprio JSP - <%@ page isELIgnored=”true” %>)

<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<el-ignored>true</el-ignored>
</jsp-property-group>
</jsp-config>

Capítulo 8

- Ações padrão de bean (são traduzidas como locais – _jspService() ):

<jsp:useBean id = ”person” class = “foo.Person” scope = “request” />

. Se o bean já existir, pega a referencia. Se não existir, cria um novo.
. Se não definir scope, o padrão é “page”
. Atributo type – define a referência. Se o type existir sem o class, o objeto precisa existir
. Atributo class define objeto (new) – precisa ser public, não-abstrata e possuir um construtor default
. Cuidado: segue as regras do polimorfismo, onde type é a referência e class é o objeto
. Pode usar expressão <%= %> como valor de um atributo

<jsp:getProperty name = ”person” property = “name” />

. O bean especificado precisa estar instado
. As propriedades seguem a convenção JavaBeans – são definidas pelos nomes dos métodos is, get,
set e não pelo nome do atributo.

<jsp:setProperty name = ”person” property = “name” value = “Fred” />

. Mesmas regras do jsp:getProperty
. Se estiver no corpo de um jsp:useBean, é atribuído condicionalmente à existência do bean (se o bean
não pussuir atributo class, o setProperty nunca rodará):
<jsp:useBean id = ”person” class = “foo.Person” scope = “request” >
<jsp:setProperty name = ”person” property = “name” value = “Fred” />
</jsp:useBean>


. Atributo param – permite usar direto o valor de um parâmetro de request
<jsp:setProperty name = ”person” property = “name” param = “nome” />

. Se o nome do parâmetro de request coincidir com o nome da propriedade, pode-se omitir a tag
param (<input name=”name” />):
<jsp:setProperty name = ”person” property = “name” />

. Bind automático (asterisco) – atribui todos os parâmetros de solicitação cujos nomes coincidem com
os nomes dos atributos do bean:
<jsp:setProperty name = ”person” property = “*” />

. As tags jsp:setProperty e jsp:getProperty fazem o CASTING AUTOMÁTICO dos parâmetros, tanto na
entrada (String para seu tipo) quanto na saída (seu tipo para String)

. CUIDADO: utilizando scripts, o CASTING AUTOMÁTICO NÃO FUNCIONA. Ex:
<jsp:setProperty name = ”person” property = “empID” value = “<%= 321 %>” />

. Beans complexos:
Cuidado: não pode navegar por propriedades dentro dos atributos de taglibs. Pra isso precisa
utilizar EL:
Errado:
<jsp:getProperty name = ”person” property = “dog.name” />
Correto (aqui nem precisa do jsp:useBean – ele já sabe que é o atributo person do
request):
${person.dog.name}

- Expression Language (EL)
. Operador ponto:
- para classes JavaBeans – navega pelos atributos que forneçem get set: ${meuBean.nome}
- para Maps – acessa um valor do Map pela sua chave: ${meuMap.chave}
. Operador colchete []
- para classes JavaBeans – ${meuBean[“nome”]}
- para Maps – ${meuMap[“chave”]}
- para Lists – acessa pelo índice: ${minhaLista[0]} ou ${minhaLista[“0”]}
- para vetores – acessa pelo índice: ${meuVetor[0]} ou ${meuVetor[“0”]}

Obs.: tanto faz utilizar aspas simples ‘valor’ quanto duplas “valor”

. Objetos Implícitos

Objeto Tipo Observações
pageScope Map
requestScope Map
sessionScope Map
applicationScope Map
param Map
paramValues Map de vetor ${paramValues.food[0]}
header Map
headerValues Map de vetor ${headerValues.userAgent[0]}
Cookie Map ${cookie.userName.value}
initParam Map
Único objeto JavaBean. Os
Objeto JavaBean
pageContext outros são apenas Maps de
PageContext
chave/valor

. Cuidado:
${request.method} = ERRADO (não existe atributo de nome request)
${requestScope.method} = ERRADO (são apenas Maps de chave/valor)
${pageContext.request.method} = CORRETO (pageContext é o único objeto JavaBean EL)
. Cuidado:


${initParam.email} acessa os parâmetros do CONTEXTO (que no D.D. estão context-param)

- Tipos de Include
. Diretiva: <%@ include file=”header.jsp” %> - INSERE O CÓDIGO-FONTE DA PAGINA
- O código-fonte da página filho vira código-fonte da página pai
- Cuidado: não significa que o conteúdo incluído será estático, pois o código fonte dinâmico
continua dinâmico, porém copiado dentro da página pai.
- A cópia ocorre apenas uma vez (porém containers inteligentes como o Tomcat detectam que
a página mudou e copiam denovo, mas a especificação NÃO GARANTE).
. Ação Padrão: <jsp:include page=”header.jsp” /> - INSERE A RESPOSTA DA PAGINA
- A página é chamada via dispacho, recebendo os mesmos objetos request/response, na
mesma thread/pilha.
- Na página incluída, não pode: mudar status da resposta, nem criar headers nem cookies

. Podemos enviar parâmetros de solicitação ao conteúdo incluído (apenas para a ação jsp:include e
para jsp:forward). Ele sobrescreve ou adiciona um parâmetro da solicitação (pode ser lido com
request.getParameter ou com EL):
<jsp:include page=”header.jsp” >
<jsp:param name=”titulo” value=”Página Principal” />
</jsp:include>
. A tag jsp:param também pode ser usada dentro da jsp:forward

- Ação Padrão: <jsp:forward page=”handle.jsp” />
. Limpa o buffer e faz um dispacho no JSP
. Cuidado: nunca chamar o método out.flush() antes desta ação - será impresso até o ponto do flush
(será lançada uma exceção que nem chegará ao usuário)

Capítulo 9

- Custom Tags – JSTL 1.1 (utilizadas em conjunto com EL)

. Biblioteca JSTL – core

<%@ taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>

<c:out value=”${person.name}” escapeXml=”false” default=”no name person” />

<c:out value=”${person.name}” escapeXml=”false” >
No name person
</c:out>

Obs.: escapeXml e default são opcionais – o padrão do escapeXml é true, ou seja, os caracteres são
convertidos para o padrão de escape html

<c:forEach var=”movie” items=”${movieList}” varStatus=”loopStatus” >
<tr>
<td>Índice: ${loopStatus.count}</td>
<td>${movie.title}</td>
</tr>
</c:forEach>

Obs.: movieList pode ser: Coleção, Map, array ou string delimitada por vírgulas

<c:forTokens var=”movie” items=”${movieStringOfTokens}” delims=”;” varStatus=”loopStatus” >
<tr>
<td>Índice: ${loopStatus.count}</td>
<td>${movie.title}</td>
</tr>
</c:forTokens>


Obs.: movieStringOfTokens precisa ser String, contendo o conteúdo tokenizado (ex: “movie1;movie2;movie3”)

<c:if test=”${userType eq ‘admin’}” >
<jsp:include page=”/admin.jsp” />
</c:if>

Obs.: a tag c:if não possui suporte para else

<c:choose>
<c:when test=”${userType eq ‘admin’}” >
Welcome system administrator
</c:when>

<c:when test=”${userType eq ‘teacher’}” >
Welcome teacher
</c:when>

<c:otherwise>
Welcome general user
</c:otherwise>
</c:choose>

Obs.: a tag c:choose não possui fall-through, ou seja, não precisa de break – os blocos são isolados

Utilizando var – qualquer tipo de atributo de qualquer escopo

<c:set var=”userLevel” scope=”session” value=”Cowboy” />

<c:set var=”userLevel” scope=”session” >
Cowboy
</c:set>

<c:set var”fido” value=”%{person.dog}” />

Utilizando target – propriedades de Beans e valores de Maps

<c:set target=”${petMap}” property=”dogName” value=”Clover” />

<c:set target=”${person}” property=”name” value=”Billy” />

<c:set target=”${person}” property=”name” >
Billy
</c:set>

Obs.: vide final da tabela

<c:remove var=”userStatus” scope=”request” />

Obs.: o escopo é opcional – padrão é Page, e var precisa ser uma string literal, não uma expressão

<c:import url=”http://www.othersite.com.br/otherpage.html” />

<c:import url=”http://www.othersite.com.br/otherpage.html” >
<c:param name=”subtitle” value=”We take the soap” />
</c:import>


Obs.: funciona como os dois includes, porém pode incluir um conteúdo que esteja fora do container (em tempo
de solicitação – idem jsp:include)

<a href=”<c:url value=’/coments.jsp’ />”>Comentarios</a>

<c:set var=”name” value=”Gilberto Holms” />
<c:url value=’/coments.jsp?name=${name}’ var=’inputURL’ />
Obs.: Resultado: /myApp/comments.jsp?name=Gilberto Holms (notar espaços na url – não foi codificada)

<c:url value=’/coments.jsp’ var=’inputURL’ >
<c:param name=”name” value=”Gilberto Holms” />
</c:url>
Obs.: Resultado: /myApp/comments.jsp?name=Gilberto+Holms (notar que url é codificada corretamente)

<c:redirect url=”http://www.google.com” />

Codigo arriscado...
<c:catch>
<% int x = 10/0; %>
Não passará nunca por aqui
</c:catch>
Pulará para cá!

Codigo arriscado...
<c:catch var=”myException”>
<% int x = 10/0; %>
Não passará nunca por aqui
</c:catch>
Pulará para cá!
<c:if test=”${myException != null}” >
Ocorreu um erro! Mensagem: ${myException.message}
</c:if>

Obs.: ao ocorrer o erro, o fluxo pula para o fim da tag </c:catch>, lembrando que se não for uma página de
erro declarada com (isErrorPage=”true”), não podemos fazer ${pageContext.exception}. Precisamos utilizar o
atributo var.
Cuidado: não existe try nem finally, e nada roda dentro do bloco c:catch depois do ponto em que ocorreu a
exceção.
Cuidado: é impossível utilizar informações do atributo var dentro do bloco c:catch, apenas depois dele.

- Observações gerais:
. Tag c:set
Utilizando var:
- se o atributo ainda não existir, ele será criado
- se não especificar escopo, ele procura em todos a partir do mais restrito (page -> )
- se o value for nulo, o atributo será removido
- o value pode ser qualquer objeto que possa ser resolvido (por EL, por <%= %> ou
jsp:attribute)

Utilizando target:
- o target não pode ser nulo, e nem é uma String representando ids de beans – ele
precisa ser um objeto que possa ser resolvido (por EL, por <%= %> ou jsp:attribute)

Principais pegadinhas:
- target e var não podem coexistir


- scope é opcional – na hora de procurar, procura nos quatro – se não achar, na hora
de criar, cria no Page
- se target for nulo, o container gera exceção
- se target não for um bean nem um Map, o container gera exceção
- se o bean representado em target não tiver a propriedade especificada em property, o
container gera exceção (a EL não gera – ela traz nulo, mas o container gerará)
- cuidado com targets especificando strings id de beans – o correto é o próprio objeto

- Páginas de Erro:

. Abordagem por página:
Na página que trata os erros:
<%@ page isErrorPage=”true” %>

Na página defeituosa:
<%@ page errorPage=”errorPage.jsp” %>

. Abordagem para a aplicação toda (no D.D.):
Ex.: direciona TODAS as exceções:
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/errorPage.jsp</location>
</error-page>

Ex.: direciona por tipo de exceção:
<error-page>
<exception-type>java.lang.ArithmeticException</exception-type>
<location>/arithmeticErrorPage.jsp</location>
</error-page>

Ex.: direciona por código de status de resposta http:
<error-page>
<error-code>404</error-code>
<location>/notFoundError.jsp</location>
</error-page>

Obs.:
1 - O redirecionamento para a página de erro é feito pelo container (dispatch), portanto a url
do browser cliente não muda
2 - Não pode utilizar exception-type e error-code juntos na mesma
Tag
3 – Podemos lançar erros http (ou códigos de status) via programação:
response.sendError(HttpServletResponse.SC_FORBIDDEN); //ou também
response.sendError(403);

. Objeto implícito exception:
- presente apenas nas páginas de erro configuradas com <%@ page isErrorPage=”true” %> ,
ou seja, configurar apenas no D.D. não é suficiente para se obter um objeto exception na
página
- ele é do tipo Java.lang.Throwable:
Scriptlet: <%= exception.getMessage(); //e outros métodos da interface %>
EL: ${pageContext.exception.message} ou ${pageContext.exception.stackTrace}

Capítulo 10

- Tags Customizadas – tipo Simples
. Arquivo TLD
<taglib ... >
<uri>randomThings</uri> nome único que identifica a taglib (+/- obrigatório)
<tag>
<description>This is a random advice</description> descrição qualquer
<name>advice</name> nome da tag (obrigatório)
<tag-class>foo.AdvisorTagHandler</tag-class> classe da tag (obrigatório)


<body-content>empty</body-content> tag não terá corpo (obrigatório)

<attribute> obrigatório um para cada atributo da tag
<name>user</name> nome do atributo
<required>true</required> diz se o atributo é obrigatório
<rtexprvalue>true</rtexprvalue> diz se pode ser uma expressão
</attribute>
</tag>
</taglib>

. No JSP
<%@ taglib prefix=”mine” uri=”randomThings” %>

<mine:advice user=”Gilberto Holms” />

<mine:advice user=”${userName}” />

<mine:advice user=”${userName}” > </mine:advice> não é body-content

<mine:advice user=”<%=request.getAttribute(“userName”) %>” />

<mine:advice>
<jsp:attribute name=”user”>${userName}</jsp:attribute> não é body-content
</mine:advice>

. Classe TagHandler – SimpleTagSupport (javax.servlet.jsp.tagext)
public class AdvisorTagHandler extends SimpleTagSupport { //classe pai
private String user;

public void setUser(String user) { //set do atributo na convenção JavaBeans
this.user = user;
}

//método chamado quando o JSP invoca a tag
public void doTag() throws JspException, IOException {
getJspContext().getOut().write(“Hello “ + user + “<br>”);
}

//outros métodos quaisquer
}

. Tag handler que usa body-content:

public class AdvisorTagHandler extends SimpleTagSupport { //classe pai
private String user;

public void setUser(String user) {
this.user = user;
}

public void doTag() throws JspException, IOException {
getJspBody().invoke(null); //processa o corpo da tag e exibe na resposta
//o argumento null significa que o output vai para a resposta, e não para
//algum outro writer
}

//Obs.: o invoke pode ser chamado várias vezes, podendo ter conteúdos diferentes
}

. Ciclo de Vida da Tag Simples
1. Carrega a classe


2. Executa construtor padrão
3. Chama setJspContext(JspContext) – injeta uma referência ao JspContext do JSP
4. Se a tag estiver aninhada, chama setParent(JspTag) – tags aninhadas podem se comunicar
5. Se a tag tiver atributos, chama seus setters
6. Se seu body-content não for empty (e se a tag for realmente chamada com um corpo),
chama setJspBody(JspFragment)
7. Chama método doTag() – o qual substituimos

. Observações
- se o rtexprvalue for falso ou não estiver definido, significa que só é possível utilizar uma string
literal como valor desse atributo
- existe o atributo opcional <type>, que informa o tipo esperado (nome da classe
completamente qualificado), porém de qualquer forma o container tenta resolver o tipo digitado
para o tipo do método setter da classe TagHandler
- o <uri> precisa ser único para toda a aplicação, mesmo em arquivos TLD separados
- atributo de corpo nas tags:
<body-content>empty</body-content> não pode ter corpo (apenas jsp:attribute)
<body-content>scriptless</body-content> pode apenas texto, EL e outras tags
<body-content>tagdependent</body-content> nada calculado – tudo vira texto puro
<body-content>JSP</body-content> pode qualquer coisa que possa ser JSP
- a tag pode lançar exceções:
JspException – destrói/propaga pela página (tag e JSP invocador)
SkipPageException – mantém na resposta o que está acima do throw (tag e JSP
invocador) – no caso de um include que contém esta tag, ela interrompe apenas a
página que contém diretamente a tag
- ao final de cada chamada de tag, o objeto tag handler é destruído (não há problemas de
estado do objeto)
- a tag pode definir um atributo utilizado externamente no seu corpo chamando
getJspContext.setAttribute, e modificá-lo quantas vezes quiser onde o getJspBody.invoke
refletirá as mudanças

- localização dos TLDs (em ordem de busca):
1. No D.D. – não é obrigatório, mas se for definido, tem prioridade
<jsp-config>
<taglib>
<taglib-uri>randomThings</taglib-uri>
<taglib-location>/WEB-INF/myFunctions.tld</taglib-location>
</taglib>
</jsp-config>
2. Dentro de subdiretórios de WEB-INF
3. Dentro do META-INF DE UM JAR que esteja dentro de WEB-INF/lib
4. Dentro de SUBDIRETÓRIOS DO META-INF DE UM JAR que esteja dentro de
WEB-INF/lib

- prefixos reservados – não pode usar
jsp – jspx – java – javax – servlet – sun – sunw

- Tags Customizadas – tipo Clássico
. Arquivo TLD: idêntico ao tipo simples
. No JSP: idêntico ao tipo simples
. Classe TagHandler –TagSupport ou BodyTagSupport (javax.servlet.jsp.tagext)

Métodos Descrição Constantes Retorno
SKIP_BODY
int doStartTag() E depois, devo avaliar o corpo ?
EVAL_BODY_INCLUDE
SKIP_BODY
int doAfterBody() E depois, avalio o corpo novamente ?
EVAL_BODY_AGAIN
SKIP_PAGE
int doEndTag() E depois, avalio o resto da página ?
EVAL_PAGE
Obs.:
- EVAL_BODY_AGAIN é definida no tipo IterationTag
- Retornar SKIP_PAGE do doEndTag() é equivalente ao lançar uma SkipPageException
- As constantes em negrito são o retorno padrão quando o método não é anulado


- Os atributos do corpo são setados/obtidos através do objeto pageContext (e não do método
getJspContext() como na tag simples)
- O método doAfterBody() roda depois de o corpo já ter sido processado 1 vez, ou seja, a lógica inicial
precisa estar no doStartTag()
- Cuidado: tags clássicos podem ser reutilizados pelo container, ou seja, são statefull (inicialize
variáveis de instância apenas no doStartTag)
- Cuidado: manter coerente as constantes de retorno com o body-content do TLD
- TagSupport não oferece acesso ao conteúdo do corpo da tag
- Utilizando BodyTagSuppor – utilizado para obter acesso ao conteúdo do corpo
. Dois novos métodos: setBodyContent() – argumento Writer – e doInitBody()
. Novo retorno para o doStartTag (que torna-se o padrão) – EVAL_BODY_BUFFERED

- Aninhamento de Tags
. Método getParent()
OuterTag parent = (OuterTag) getParent();
. Tag mais alta – getParent() retorna null
. Tag clássica acessa apenas parent clássica – tag simples acessa parent clássica ou simples
. Você pode subir a hierarquia – getParent() – mas não pode descer
. Método findAncestorWithClass retorna o parent mais próximo do tipo class especificado

- Tag Files
. São alternativas para o jsp:include e c:import
. Podemos enviar parâmetros com escopo de tag (e não de solicitação)

1. Supondo um fragmento de header, renomear Header.jsp para Header.tag ou Header.tagx
2. Salvar numa pasta WEB-INF/tags
3. Incluindo a Tag File:
<%@ taglib prefix=”frags” tagdir=”/WEB-INF/tags” %>
<frags:Header /> o nome da tag será o nome do arquivo

. Utilizando atributos de escopo de tag:
- Atributo comum
Declarar no fragmento Header.tag
<%@ attribute name=”subTitle” required=”true” rtexprvalue=”true” %>
<h1>${subTitle}</h1>

Usando na JSP
<frags:Header subTitle=”${subTitleName}” />

- Atributo de corpo
Declarar no fragmento Header.tag
<h1><jsp:doBody /></h1>

Usando na JSP
<frags:Header >
Meu atributo realmente grande
</frags:Header>

Neste caso podemos declarar body-contente – o padrão é scriptless
<%@ tag body-content=”tagdependent” %>
<h1><jsp:doBody /></h1>
Obs.: para Tag Files é PROIBIDO o body-content tipo JSP (usamos apenas empty,
scriptless ou tagdependent)

- Atributos comuns e o atributo body-content podem coexistir na Tag File
- Podemos utilizar scripts dentro do arquivo Tag File (não pode apenas colocar scripts
externamente como body-content). Podemos também utilizar os objetos implícitos JSP e EL
- Localização das Tag Files
1. Dentro de WEB-INF/tags
2. Dentro de subdiretórios de WEB-INF/tags
3. Dentro do META-INF/tags DE UM JAR que esteja dentro de WEB-INF/lib
4. Dentro de SUBDIRETÓRIOS DO META-INF/tags DE UM JAR que esteja dentro de
WEB-INF/lib


5. Regra: APENAS se a tag file for distribuída em um jar (3 e 4), ela precisa de um TLD
especial (apenas de localização):
<taglib>
<tlib-version>1.0</tlib-version>
<uri>myTagFilesLibrary</uri>
<tag-file>
<name>Header</name>
<path>/META-INF/tags/Header.tag</path>
</tag-file>
</taglib>

Capítulo 11

- Estrutura de Diretórios

ROOT DA APLICAÇÃO
|-- *.jsp, *.html, *.css ...
|-- WEB-INF
|-- *.tld (ou qualquer subdir)
|-- web.xml
|-- lib
|-- classes
|-- tags
|-- *.tag, *.tagx
|-- META-INF
|-- MANIFEST.MF

- Pasta META-INF
. Utilizada apenas para distribuir em um WAR
. No arquivo MANIFEST.MF pode-se declarar dependências verificadas em tempo de distribuição

- Cuidado: os diretórios WEB-INF e META-INF são protegidos – não é possível acesso direto por clientes
(retorna erro 404 – Page Not Found), mas é possível guardar recursos internos normalmente (jsp, etc)
- Obtendo recursos que não são classes:
getResource() e getResourceAsStream()
. A partir do ServletContext – apenas recursos que não estão empacotados em JAR
. A partir do classloader – recursos empacotados em JAR (idem J2SE)

- Regras mapeamento de Servlets:
/Beer/selectBeer.do
/Beer/* (terminando com /*)
*.do (começa com * - não pode ter barra)

. No caso de mais de um mapeamento pro mesmo servlet, o mais específico vence
. Cuidado: na requisição, MyApp/foo/bar (mapeia para /foo/bar) é diferente de MyApp/foo/bar/
(mapeia para /foo/bar/*)

- Página default – o container procura com a prioridade iniciando na primeira da lista – vale para todas as
pastas da aplicação que forem requisitadas parcialmente:
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>

. Cuidado: não inicia com barra
. A prioridade ainda maior é se existe um mapeamento de servlet para o parcial requisitado

- Inicializando servlets – a tag load-on-startup faz com que o container carregue o servlet na distribuição, ates
até da primeira solicitação do cliente. Um inteiro não negativo habilita a opção, e seu valor indica a ordem em
que os servlets serão inicializados
<servlet>


<servlet-class>br.com.MinhaClasseServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

. Pegadinha: o valor não é o número de instâncias que serão criadas – é apenas a ordem

- Sintaxe XML para JSP

Sintaxe JSP Sintaxe XML Equivalente
<%@ page import=”java.util.*” %> <jsp:directive.page import=”java.util.*” />
<%! int y = 3; %> <jsp:declaration> int y = 3; </jsp:declaration>
<% list.add(“giba”); %> <jsp:scriptlet> list.add(“giba”); </jsp:scriptlet>
Any plain text <jsp:text>Any plain text</jsp:text>
<%= it.next() %> <jsp:expression> it.next() </jsp:expression>

- Referenciando components EJB (apenas containers J2EE completos)
. Bean Local (na mesma VM):
<ejb-local-ref>
<ejb-ref-name>ejb/Customer<ejb-ref-name> - nome JNDI do Bean
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>com.teste.CustomerHome</local-home>
<local>com.teste.Customer</local>
</ejb-local-ref>

. Bean Remoto (em outra VM):
<ejb-ref>
<ejb-ref-name>ejb/Customer<ejb-ref-name> - nome JNDI do Bean
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.teste.CustomerHome</home>
<remote>com.teste.Customer</remote>
</ejb-ref>

Cuidado: não existe <ejb-remote-ref> nem <remote-home>

- Enviando parâmetros para a aplicação do tipo Object via JNDI (apenas containers J2EE completos)
<env-entry>
<env-entry-name>rates/discountRate</env-entry-name> - nome JNDI a ser bindado
<env-entry-type>java.lang.Integer</env-entry-type> - obrigatório construtor String ou Character
<env-entry-value>10</env-entry-value> - valor (será traduzido String ou Character)
<env-entry>

. Cuidado: env-entry-type não pode ser tipo primitivo

- Elemento de mapeamento mime-type de arquivos:
<mime-mapping>
<extension>mpg</extension> - não inclua o ponto
<mime-type>video/mpeg</mime-type>
</mime-mapping>

Capítulo 12

- Conceitos de Segurança:
. Autenticação – é quem diz ser
. Autorização – pode acessar um recurso
. Confidencialidade – mais ninguém pode olhar os dados
. Integridade – ninguém pode modificar os dados

- Container deve fornecer tabela relacionando username, password e papel – essa tabela é o realm


- Implementando mecanismos segurança declarativos no D.D.:
. Autenticação:
<security-role> - precisam estar declaradas no realm do container
<role-name>Admin</role-name>
<role-name>Member</role-name>
<role-name>Guest</role-name>
</security-role>

<login-config> - habilita a autenticação
<auth-method>BASIC</auth-method>
</login-config>

. Autorização:
<security-constraint>
<web-resource-collection>
<web-resource-name>UpdateRecipes</web-resource-name> - obrigatório

<url-pattern>/Beer/AddRecipe/*</url-pattern> - recursos a restringir
<url-pattern>/Beer/ReviewRecipe/*</url-pattern>

<http-method>GET</http-method> - métodos a restringir
<http-method>POST</http-method>

<auth-constraint>
<role-name>Admin</role-name> - papéis autorizados
<auth-constraint>
</security-constraint>

. Regras para web-resource-collection:
- url-pattern – obrigatório ao menos um (mesmas regras que o do servlet)
- http-method – opcional (quando mais de um, os outros não declarados são
autorizados) – podemos utilizar todos exceto CONNECT
- se não houver nenhum http-method, TODOS serão restringidos
- web-resource-name – obrigatório (mas não se refere a nada)
- um elemento <description> é opcional
- pode haver mais de um grupo web-resource-collection na mesma constraint
- as restrições não são a nível de recurso e sim a nível de solicitação HTTP
. Regras para auth-constraint:
- um elemento auth-constraint é opcional – se não houver, é permitido o acesso não-
autenticado
- um elemento <description> é opcional
- Cuidado: a tag <auth-constraint /> VAZIA é oposto a NENHUMA tag auth-constraint
. Regras para role-name:
- elementos role-name são opcionais – quando mais de um, os outros não declarados
são restringidos
- se não houver nenhum role-name, TODOS papéis serão restringidos
- podemos utilizar <role-name>*</role-name> para autorizar todos os papéis
- os nomes dos papéis são case-sensitive

- Cuidado: podemos ter elementos auth-constraint conflitantes para o mesmo recurso em
security-constraits diferentes:

Conteúdo de A Conteúdo de B Quem é Permitido
<auth-constraint> <auth-constraint>
<role-name>Guest</role-name> <role-name>Admin</role-name> AMBOS
TODOS
<role-name>Guest</role-name> <role-name>*</role-name>


<auth-constraint /> <auth-constraint>
(TAG VAZIA) <role-name>Admin</role-name> NINGUÉM
<auth-constraint>
(NENHUM ELEMENTO) <auth-constraint>
<role-name>Admin</role-name> TODOS
<auth-constraint>

- Segurança programática
. Método: request.isUserInRole(String role)
. Regras:
- Se usuário não estiver autenticado, retorna falso
- Procura primeiro um mapeamento para uma role real, se não encontrar, procura uma role real
de mesmo nome:
<servlet>
<security-role-ref>
<role-name>Manager</role-name> - role do código
<role-link>Admin</role-link> - role real (security-role do D.D.)
</security-role-ref>
</servlet>

- Tipos de Autenticação
. BASIC – apenas critografia base64
. DIGEST – uma criptografia mais segura, nem todos containers implementam
. CLIENT-CERT – obriga que o cliente possua um certificado (Public Key Certificate – PKC)
. FORM – utiliza um form HTML customizado

Tipo Spec Observações
BASIC HTTP Fraca – criptografia base64
Mais forte, mas sem SSL (o container não é obrigado
DIGEST HTTP
a suportá-la)
Forte – obriga que o cliente possua um certificado
CLIENT-CERT J2EE
(Public Key Certificate – PKC)
Muito fraca – sem criptografia, utiliza form de login
FORM J2EE
customizado
. Implementando autenticação FORM:
- No D.D.:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/loginPage.html</form-login-page>
<form-error-page>/loginError.html</form-error-page>
</form-login-config>
<login-config>

- Na página de login:
<form method=”POST” action=”j_security_check”>
<input type”text” name=”j_username”>
<input type=”password” name=”j_password”>
<input type=”submit” value=”Enviar”>
</form>

- Confidenciabilidade e Integridade dos dados:
. São garantidos através de posts utilizando HTTPS sobre SSL ativado pelo container
. No D.D., declaramos:
<security-constraint>
<web-resource-name>UpdateRecipes</web-resource-name>

<url-pattern>/Beer/AddRecipe/*</url-pattern>
<url-pattern>/Beer/ReviewRecipe/*</url-pattern>


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

<auth-constraint>
<role-name>Admin</role-name>
<auth-constraint>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

. Tipos de transport-guarantee:
NONE – é o padrão, não haverá proteção dos dados
INTEGRAL – os dados não podem ser modificados
CONFIDENTIAL – os dados não poderão ser vistos por ninguém

Capítulo 13

- Utilizando Filtros

public class BeerFilter implements Filter {

public void init(FilterConfig config) throws ServletException {
//pode salvar o FilterConfig para utilizar depois
}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws
ServletException, IOException {

//código que será executado na IDA (request)
chain.doFilter(request, response); //dá continuidade à cadeia de filtros
//código que será executado na VOLTA (response)
}

public void destroy() {
//codigo de limpeza...
}

}

- Observações:
. O pacote que contém as interfces de filtro é: javax.servlet.*
. O filtro por padrão não possui vínculo ao HTTP
. Cuidado: é ServletRequest e ServletResponse (não as suas versões http)
. É obrigatório anular os três métodos de ciclo de vida do Filtro
. O método doFilter chama o próximo filtro, ou se for o fim da pilha, chama o recurso solicitado
. É chamado empilhadamente – 1 vez na requisição e 1 vez na resposta da solicitação
. Declarando no D.D. (semelhante aos servlets):

<filter>
<filter-name>BeerRequest</filter-name>
<filter-class>com.example.BeerFilter</filter-class>
<init-param>
<param-name>email</param-name>
<param-value>gibaholms@hotmail.com</param-value>
</init-param>
</filter>

<filter-mapping>


<url-pattern>*.do</url-pattern> - ou ainda <servlet-name>BeerServlet</servlet-name>
</filter-mapping>

. No elemento filter, é obrigatório filter-name e filter-class
. No elemento filter-mapping, é obrigatório filter-name e OU url-pattern OU servlet-name
. Definição da ordem de execução para filtros com mais de um mapeamento:
1. Os filtros com url-pattern serão localizados primeiro
2. Eles terão a mesma ordem em que estiverem declarados no D.D.
3. Em seguida, os filtros com servlet-name são localizados
4. Também seguirão a ordem de declaração no D.D.
. A partir da espec. JSP 2.4, os filtros também podem ser invocados através de include, forward ou
handler de erros (podemos ter de 0 a 4 elementos dispatcher no mapeamento):

<filter-mapping>
<url-pattern>*.do</url-pattern>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>

. Tipos de dispatcher:
REQUEST – se não houver nenhum, ele é o padrão
INCLUDE – ativa o filtro para uma chamada include()
FORWARD – ativa o filtro para uma chamada forward()
ERROR – ativa o filtro para recursos chamados pelo handler de erros

- Cuidado: quando o filtro passa o controle para o servlet enviando o response original, este é enviado
diretamente para o container na volta, não retornando pelo filtro. O filtro é executado novamente (após a
chamada chain.doFilter), porém o stream de saída já foi enviado ao cliente. Neste caso, precisamos enviar um
objeto resposta falso (wrapper).

- Classes Wrappers de solicitação e repsosta (também conhecidos como design pattern Decorator)
. ServletRequestWrapper
. HttpServletRequestWrapper
. ServletResponseWrapper
. HttpServletResponseWrapper

Exemplo simplificado de uso:

public class CompressionResponseWrapper extends HttpServletResponseWrapper {

private GZipSerletOutputStream servletGZipOS;

//substituição dos métodos necessários

public ServletOutputStream getOutputStream() throws IOException {
servletGZipOS = new GZipSerletOutputStream(getResponse().getOutputStream());
return servletGZipOS;
}

}

public class CompressionFilter implements Filter {

public void init(FilterConfig config) throws ServletException { }

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws ServletException, IOException {

CompressionResponseWrapper wrappedResp =
new CompressionResponseWrapper(response);
chain.doFilter(request, wrappedResp);


//código que envia os dados do stream comprimido GZip para o stream de resposta
original e limpa o buffer comprimido
}

public void destroy() { }

}

Capítulo 14

- Service Locator
Encapsula a busca JNDI (lookup) ao objeto remoto, ou UDDI se for um serviço, ou outro mecanismo
qualquer de localização de objetos.

- Business Delegate
Encapsula as chamadas a objetos remotos, realizando as operações necessárias para obter o Stub (ou
Proxy) e invocar suas operações, podendo também tratar os erros de i/o remoto. Se utilizado junto com
Transfer Object, é ele quem obtêm o T.O. através do Stub.

- Transfer Object
É um objeto JavaBean que é transmitido inteiramente do servidor remoto para o local (serializado),
onde a chamada remota é feita apenas uma vez. È utilizado para que a View não precise utilizar o Stub como
model, o que causaria muitas chamadas remotas de pequena granularidade. Desta forma a View utiliza o V.O.
como model, que se torna um objeto local. Inconveniente: os dados do V.O. ficam fora de sincronismo
(desatualizados) com o valor remoto.


- Intercepting Filter
É um objeto que intercepta uma chamada, podendo realizar modificações antes da chamada e após a
chamada, sem que o objeto chamado precisa saber que está sendo interceptado. Ex.: classes Filter

- Model-View-Controller
. Model: uma classe Java – armazena a lógica de negócio e o estado, é a única parte da aplicação que
pode falar com o banco de dados.
. View: um JSP – responsável pela apresentação, obtém o estado do modelo através do controlador
(não diretamente, o controlador disponibiliza o modelo atualizado em um lugar comum que a view também
possa acessar)
. Controller: um Servlet – recebe a solicitação do usuário, invoca o modelo e torna o novo modelo
atualizado disponível para a view

- Front Controller
É quando se implementa um modelo MVC com um único controlador, que é o ponto de encontro de
todas as solicitações, ou seja, todas as solicitações passam por ele e ele se encarrega de fazer o dispatch para
os lugares apropriados. Ex.: o framework Struts


Resumo Anotações SCWCD 5.0

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Resumo Anotações SCWCD 5.0

Semelhante a Resumo Anotações SCWCD 5.0 (20)

Resumo Anotações SCWCD 5.0