Resumo Anotacoes Certificacao SCWCD 5

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

Resumo Anotações para Certificação SCWCD 5.0 Gilberto Augusto Holms @gibaholms [email protected] 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> <servlet-name>nome</servlet-name> <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


- 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> <param-name>nome</param-name> <param-value>valor</param-value>

</context-param>

Listener Evento Métodos

ServletContextListener ServletContextEvent contextInitialized contextDestroyed

ServletContextAttributeListener ServletContextAttributeEvent attributeAdded attributeReplaced attributeRemoved

ServletRequestListener ServletRequestEvent requestInitialized requestDestroyed

ServletRequestAttributeListener ServletRequestAttributeEvent attributeAdded attributeReplaced attributeRemoved

HttpSessionListener HttpSessionEvent sessionCreated sessionDestroyed

HttpSessionAttributeListener HttpSessionBindingEvent attributeAdded attributeReplaced attributeRemoved

HttpSessionActivationListener HttpSessionEvent sessionDidActivate sessionWillPassivate

HttpSessionBindingListener HttpSessionBindingEvent valueBound 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

out JspWriter É um PrintWriter com mais funcionalidades

request HttpServletRequest

response HttpServletResponse session HttpSession

application ServletContext config ServletConfig

pageContext PageContext Encapsula chamadas para os 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>

<param-name>nome</param-name> <param-value>valor</param-value>

</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

pageContext Objeto JavaBean

PageContext

Único objeto JavaBean. Os outros são apenas Maps de 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óri o) <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

int doStartTag() E depois, devo avaliar o corpo ? SKIP_BODY

EVAL_BODY_INCLUDE

int doAfterBody() E depois, avalio o corpo novamente ? SKIP_BODY

EVAL_BODY_AGAIN

int doEndTag() E depois, avalio o resto da página ? SKIP_PAGE 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 cont eú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-name>nome</servlet-name>


<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> <web-resource-collection> <auth-constraint> <role-name>Admin</role-name> - papéis autorizados <role-name>Member</role-name> <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> <role-name>Guest</role-name> <auth-constraint>

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

AMBOS

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

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

TODOS


<auth-constraint> <auth-constraint> <auth-constraint /> (TAG VAZIA)

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

NINGUÉM

(NENHUM ELEMENTO) <auth-constraint> <role-name>Admin</role-name> <auth-constraint>

TODOS

- 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

DIGEST HTTP Mais forte, mas sem SSL (o container não é obrigado a suportá-la)

CLIENT-CERT J2EE Forte – obriga que o cliente possua um certificado (Public Key Certificate – PKC)

FORM J2EE Muito fraca – sem criptografia, utiliza form de login 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-collection>

<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> <web-resource-collection> <auth-constraint> <role-name>Admin</role-name> <role-name>Member</role-name> <auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-gu arantee> </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>[email protected]</param-value> </init-param> </filter>

<filter-mapping> <filter-name>BeerRequest</filter-name>


<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> <filter-name>BeerRequest</filter-name> <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 Anotacoes Certificacao SCWCD 5

Documents

Transcript of Resumo Anotacoes Certificacao SCWCD 5