Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Qualidade com o JSFUnit - Artigo Java Magazine 91
Testes unitários em aplicações que utilizam a tecnologia JSF. São apresentadas, de maneira prática, as principais características do framework JSFUnit, e como sua utilização pode auxiliar o desen-volvedor na identificação de erros na aplicação.
Java Magazine 91
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 91
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 91
Qualidade com o JSFUnit
Testando aplicações JSF com o framework JSFUnit 1.3
Aprenda como o framework de testes JSFUnit pode turbinar ainda mais suas aplicações JSF
De que se trata o artigo:
Testes unitários em aplicações que utilizam a tecnologia JSF. São apresentadas, de maneira prática, as principais características do framework JSFUnit, e como sua utilização pode auxiliar o desen-volvedor na identificação de erros na aplicação.
Para que serve:
JSFUnit é um framework de testes unitários para aplicações JSF que segue as metodologias de caixa-branca e caixa-preta. Os testes podem ser executados tanto dentro do container quanto fora, pois o framework permite que ocorram requisições HTTP reais ao servidor.
Em que situação o tema é útil:
Frameworks como WebTest, HttpUnit, HtmlUnit e Selenium testam a aplicação somente do lado cliente, pois são focados na metodologia caixa-preta de testes para aplicações web. Já com JSFUnit é possível testar tanto o lado cliente quanto o lado servidor. Assim, se o ambiente estiver dentro de um container real não há a necessidade de se criar objetos mock para a realização dos testes.
Resumo DevMan:
Iniciamos o artigo com uma breve introdução sobre testes unitários, apresentamos as características fundamentais do framework JSFUnit e seus principais benefícios. Em seguida, analisamos um simples estudo de caso, onde é demonstrado passo-a-passo como criar uma aplicação JSF 2.0 – des-de a configuração do ambiente até a execução dos testes unitários utilizando o JSFUnit.
Este artigo tem como foco principal apresentar as características fundamentais do framework JSFUnit, tecnologia que auxilia no teste de aplicações que utilizam JavaServer Faces. Para garantir que o software tenha uma melhor qualidade, sendo ele web ou não, é desejável que em seu processo de desenvolvimento sejam realizados testes unitários. O teste unitário garante a qualidade do sistema, pois é ele que certifica que o código produz o resultado esperado, aumentando a qualidade do produto antes de ser entregue ao cliente.
Testes têm se tornado um aspecto importante, principalmente em aplicações corporativas. Apesar disso, atualmente existem poucos frameworks que são focados especificamente em testes unitários para aplicações JSF. Muitos dos frameworks de testes para aplicações web seguem a metodologia de caixa-preta, onde os desenvolvedores utilizam componentes web para verificar se o HTML renderizado é o esperado. Neste contexto podemos citar frameworks como HtmlUnit, HttpUnit, Canoo WebTest e Selenium, que se limitam a examinar o lado cliente das aplicações web.
A escassez de frameworks voltados à metodologia caixa-branca motivou a comunidade JBoss na criação do JSFUnit. Ele provê uma tentativa de trazer os recursos de teste para as aplicações, proporcionando uma cobertura mais ampla. Os testes são executados dentro do container, fornecendo ao desenvolvedor total acesso ao estado dos managed beans, ao FacesContext, a Expression Languages, a árvore de componentes interna e permite acesso ao HTML gerado após cada requisição.
O Que é Teste Unitário?
Devido à popularização das metodologias ágeis de desenvolvimento como a Extreme Programming (XP) e o TDD (Test Driven Development), a utilização de testes unitários foi adotada fortemente pela comunidade Java. Testes unitários são uma das práticas do XP que tem conquistado mais aceitação das equipes de desenvolvimento de software.
Um teste unitário verifica se um método produz o resultado esperado quando uma entrada conheci-da é fornecida. A ideia por trás do conceito é diminuir os erros decorrentes dos projetos de software, além de melhorar o processo de implementação, promover o trabalho em equipe e servir de documentação para o desenvolvedor.
A capacidade de elaboração de testes unitários está cada vez mais sendo cobrada do profissional que trabalha com software. É de responsabilidade do programador a criação e execução de testes unitários durante a implementação do sistema. A mesma pessoa faz o planejamento, codificação e execução do teste de unidade, onde o objetivo é encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.
A fase de testes unitários é onde se avaliam as menores unidades de software implementadas, sen-do considerada uma das etapas mais importantes do desenvolvimento. Nesta técnica busca-se iden-tificar bugs o mais cedo possível, o que pode resultar em uma excelente estratégia para obter soft-ware de melhor qualidade.
Testes em aplicações web
Aplicações web são difíceis de testar pois dependem da comunicação com o container. É bem mais complicado testar páginas web do que classes Java, pois aplicações web não permitem que verifi-quemos se o conteúdo presente nas páginas é realmente o esperado. Tanto páginas JSP quanto Ser-vlets são um tanto quanto complexas quando submetidas a testes, pois é necessário um container rodando para que suas funcionalidades sejam avaliadas. Como as páginas JSP não existem até que o deployment seja feito dentro do container web, encontramos mais um impedimento. Além disso, algumas informações importantes que precisam ser avaliadas encontram-se misturadas com tags HTML. Outro obstáculo é a mudança do layout das aplicações web, que ocorre com frequência.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Testando aplicações JSF com o framework JSFUnit 1.3
Aprenda como o framework de testes JSFUnit pode turbinar ainda mais suas aplicações JSF
De que se trata o artigo:
Testes unitários em aplicações que utilizam a tecnologia JSF. São apresentadas, de maneira prática, as principais características do framework JSFUnit, e como sua utilização pode auxiliar o desen-volvedor na identificação de erros na aplicação.
Para que serve:
JSFUnit é um framework de testes unitários para aplicações JSF que segue as metodologias de caixa-branca e caixa-preta. Os testes podem ser executados tanto dentro do container quanto fora, pois o framework permite que ocorram requisições HTTP reais ao servidor.
Em que situação o tema é útil:
Frameworks como WebTest, HttpUnit, HtmlUnit e Selenium testam a aplicação somente do lado cliente, pois são focados na metodologia caixa-preta de testes para aplicações web. Já com JSFUnit é possível testar tanto o lado cliente quanto o lado servidor. Assim, se o ambiente estiver dentro de um container real não há a necessidade de se criar objetos mock para a realização dos testes.
Resumo DevMan:
Iniciamos o artigo com uma breve introdução sobre testes unitários, apresentamos as características fundamentais do framework JSFUnit e seus principais benefícios. Em seguida, analisamos um simples estudo de caso, onde é demonstrado passo-a-passo como criar uma aplicação JSF 2.0 – des-de a configuração do ambiente até a execução dos testes unitários utilizando o JSFUnit.
Este artigo tem como foco principal apresentar as características fundamentais do framework JSFUnit, tecnologia que auxilia no teste de aplicações que utilizam JavaServer Faces. Para garantir que o software tenha uma melhor qualidade, sendo ele web ou não, é desejável que em seu processo de desenvolvimento sejam realizados testes unitários. O teste unitário garante a qualidade do sistema, pois é ele que certifica que o código produz o resultado esperado, aumentando a qualidade do produto antes de ser entregue ao cliente.
Testes têm se tornado um aspecto importante, principalmente em aplicações corporativas. Apesar disso, atualmente existem poucos frameworks que são focados especificamente em testes unitários para aplicações JSF. Muitos dos frameworks de testes para aplicações web seguem a metodologia de caixa-preta, onde os desenvolvedores utilizam componentes web para verificar se o HTML renderizado é o esperado. Neste contexto podemos citar frameworks como HtmlUnit, HttpUnit, Canoo WebTest e Selenium, que se limitam a examinar o lado cliente das aplicações web.
A escassez de frameworks voltados à metodologia caixa-branca motivou a comunidade JBoss na criação do JSFUnit. Ele provê uma tentativa de trazer os recursos de teste para as aplicações, proporcionando uma cobertura mais ampla. Os testes são executados dentro do container, fornecendo ao desenvolvedor total acesso ao estado dos managed beans, ao FacesContext, a Expression Languages, a árvore de componentes interna e permite acesso ao HTML gerado após cada requisição.
O Que é Teste Unitário?
Devido à popularização das metodologias ágeis de desenvolvimento como a Extreme Programming (XP) e o TDD (Test Driven Development), a utilização de testes unitários foi adotada fortemente pela comunidade Java. Testes unitários são uma das práticas do XP que tem conquistado mais aceitação das equipes de desenvolvimento de software.
Um teste unitário verifica se um método produz o resultado esperado quando uma entrada conheci-da é fornecida. A ideia por trás do conceito é diminuir os erros decorrentes dos projetos de software, além de melhorar o processo de implementação, promover o trabalho em equipe e servir de documentação para o desenvolvedor.
A capacidade de elaboração de testes unitários está cada vez mais sendo cobrada do profissional que trabalha com software. É de responsabilidade do programador a criação e execução de testes unitários durante a implementação do sistema. A mesma pessoa faz o planejamento, codificação e execução do teste de unidade, onde o objetivo é encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.
A fase de testes unitários é onde se avaliam as menores unidades de software implementadas, sen-do considerada uma das etapas mais importantes do desenvolvimento. Nesta técnica busca-se iden-tificar bugs o mais cedo possível, o que pode resultar em uma excelente estratégia para obter soft-ware de melhor qualidade.
Testes em aplicações web
Aplicações web são difíceis de testar pois dependem da comunicação com o container. É bem mais complicado testar páginas web do que classes Java, pois aplicações web não permitem que verifi-quemos se o conteúdo presente nas páginas é realmente o esperado. Tanto páginas JSP quanto Ser-vlets são um tanto quanto complexas quando submetidas a testes, pois é necessário um container rodando para que suas funcionalidades sejam avaliadas. Como as páginas JSP não existem até que o deployment seja feito dentro do container web, encontramos mais um impedimento. Além disso, algumas informações importantes que precisam ser avaliadas encontram-se misturadas com tags HTML. Outro obstáculo é a mudança do layout das aplicações web, que ocorre com frequência.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
9 COMENTÁRIOS
Caio Cesar Fantini
em 29/5/2011 16:40 - Responder
Oi DevMedia.
O autor diz "Neste momento o ambiente está configurado e pronto para executar a aplicação. Agora faça o download do sistema no site da revista e descompacte o arquivo em seu workspace."
Onde vocês disponibilizaram o projeto para download?
Obrigado.
O autor diz "Neste momento o ambiente está configurado e pronto para executar a aplicação. Agora faça o download do sistema no site da revista e descompacte o arquivo em seu workspace."
Onde vocês disponibilizaram o projeto para download?
Obrigado.
em 29/5/2011 16:40 - Responder
[Comentário do autor]
Sérgio Fantin
em 29/5/2011 18:32 - Responder
Sérgio Fantin
Olá Caio,
na página da edição 91 existe um link "código-fonte". Lá estão disponíveis em um único zip todos os projetos da edição.
http://www.devmedia.com.br/post-21131-Revista-Java-Magazine-91.html
Abraços...
Sérgio Fantin.
na página da edição 91 existe um link "código-fonte". Lá estão disponíveis em um único zip todos os projetos da edição.
http://www.devmedia.com.br/post-21131-Revista-Java-Magazine-91.html
Abraços...
Sérgio Fantin.
em 29/5/2011 18:32 - Responder
Caio Cesar Fantini
Ok Sérgio.
Excelente artigo. Parabéns!
Abrs
Excelente artigo. Parabéns!
Abrs
em 30/5/2011 00:42 - Responder
Davi Gomes Da Costa
em 16/6/2011 10:45 - Responder
Sérgio excelente artigo, parabéns!
Consegui rodar a aplicação de exemplo e tudo funcionou 100%, mas gostaria de fazer alguns questionamentos, tenho uma app jsf 1.2 e gostaria de saber se o jsfunit funcionaria, percebi que o tomcat chamado pelo maven foi ainda uma versão 6.0.X.
Então começo a pensar que funcionaria tb com jsf 1.2, mas queria ver se na sua experiência com esse framework se vc já testou com o 1.2.
Uma outra questão é com projetos não maven, se vc tem uma lista de jars que possa nos passar (somente os nomes dos jars obviamente) com todas as dependências do jsfunit. E se possível tb para o jsf 1.2, por exemplo o jar weld-servlet-1.0.1-Final.jar é desnecessário para essa versão do jsf, na verdade a aplicação dá até erro se colocarmos esse jar. Naturalmente não podemos alterar muitos projetos já existentes e rodando em produção para utilizar o maven somente por conta do jsfunit. Até também por conta de cliente e contrato.. e por aí vai.
Reitero minhas palavras por conta do excelente artigo e fico esperando suas considerações.
att Davi Gomes da Costa
Consegui rodar a aplicação de exemplo e tudo funcionou 100%, mas gostaria de fazer alguns questionamentos, tenho uma app jsf 1.2 e gostaria de saber se o jsfunit funcionaria, percebi que o tomcat chamado pelo maven foi ainda uma versão 6.0.X.
Então começo a pensar que funcionaria tb com jsf 1.2, mas queria ver se na sua experiência com esse framework se vc já testou com o 1.2.
Uma outra questão é com projetos não maven, se vc tem uma lista de jars que possa nos passar (somente os nomes dos jars obviamente) com todas as dependências do jsfunit. E se possível tb para o jsf 1.2, por exemplo o jar weld-servlet-1.0.1-Final.jar é desnecessário para essa versão do jsf, na verdade a aplicação dá até erro se colocarmos esse jar. Naturalmente não podemos alterar muitos projetos já existentes e rodando em produção para utilizar o maven somente por conta do jsfunit. Até também por conta de cliente e contrato.. e por aí vai.
Reitero minhas palavras por conta do excelente artigo e fico esperando suas considerações.
att Davi Gomes da Costa
em 16/6/2011 10:45 - Responder
Davi Gomes Da Costa
Estou quase chegando lá, em um projeto jsf 1.2 sem maven.
Os jars que adicionei foram esses:
weld-servlet-1.0.1-Final.jar
jboss-jsfunit-core-1.3.0.Final.jar
htmlunit-core-js-2.8.jar
httpcore-4.0.1.jar
httpclient-4.0.1.jar
xalan-2.7.1.jar
serializer-2.7.1.jar
apache-mime4j-0.6.jar
cssparser-0.9.5.jar
cactus-13-1.7.1.jar
cactus-ant-13-1.7.1.jar
httpmime-4.0.1.jar
htmlunit-2.8.jar
commons-codec-1.4.jar
nekohtml-1.9.14.jar
junit-addons-1.4.jar
commons-cli-1.0.jar
commons-httpclient-2.0.2.jar
sac-1.3.jar
xercesImpl-2.9.1.jar
xmlParserAPIs-2.6.2.jar
Adicionei essa configuração ao meu web.xml
JSFUnitFilter
org.jboss.jsfunit.framework.JSFUnitFilter
JSFUnitFilter
ServletRedirector
JSFUnitFilter
ServletTestRunner
ServletRedirector
org.jboss.jsfunit.framework.JSFUnitServletRedirector
ServletRedirector
/ServletRedirector
ServletTestRunner
org.apache.cactus.server.runner.ServletTestRunner
ServletTestRunner
/ServletTestRunner
org.jboss.weld.environment.servlet.Listener
A configuração do facelets já existia e não alterei:
Faces Servlet
javax.faces.webapp.FacesServlet
1
Faces Servlet
/faces/*
org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER
com.sun.facelets.FaceletViewHandler
facelets.VIEW_MAPPINGS
*.jspx
facelets.DEVELOPMENT
true
facelets.REFRESH_PERIOD
1
ao passar pelo meu setup debuguei e percebi que server vem com seus atributos nulos:
server = jsfSession.getJSFServerSession();
Quando executo o primeiro teste ao passar pelo código:
server.getCurrentViewID() ele está dando nullpointer exception.
Tem alguma idéia do que possa ser?
Att Davi Gomes da Costa
Os jars que adicionei foram esses:
weld-servlet-1.0.1-Final.jar
jboss-jsfunit-core-1.3.0.Final.jar
htmlunit-core-js-2.8.jar
httpcore-4.0.1.jar
httpclient-4.0.1.jar
xalan-2.7.1.jar
serializer-2.7.1.jar
apache-mime4j-0.6.jar
cssparser-0.9.5.jar
cactus-13-1.7.1.jar
cactus-ant-13-1.7.1.jar
httpmime-4.0.1.jar
htmlunit-2.8.jar
commons-codec-1.4.jar
nekohtml-1.9.14.jar
junit-addons-1.4.jar
commons-cli-1.0.jar
commons-httpclient-2.0.2.jar
sac-1.3.jar
xercesImpl-2.9.1.jar
xmlParserAPIs-2.6.2.jar
Adicionei essa configuração ao meu web.xml
A configuração do facelets já existia e não alterei:
ao passar pelo meu setup debuguei e percebi que server vem com seus atributos nulos:
server = jsfSession.getJSFServerSession();
Quando executo o primeiro teste ao passar pelo código:
server.getCurrentViewID() ele está dando nullpointer exception.
Tem alguma idéia do que possa ser?
Att Davi Gomes da Costa
em 16/6/2011 14:13 - Responder
Davi Gomes Da Costa
Este é meu erro:
java.lang.NullPointerException
at org.jboss.jsfunit.jsfsession.JSFServerSession.getCurrentViewID(JSFServerSession.java:79)
at br.com.apta.test.ClienteMBTest.testInitialPage(ClienteMBTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(AbstractCactusTestCase.java:153)
at org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.java:119)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody0(AbstractWebTestController.java:93)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody1$advice(AbstractWebTestController.java:224)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest(AbstractWebTestController.java)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(ServletTestRedirector.java:101)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$advice(ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedirector.java)
at org.jboss.jsfunit.framework.JSFUnitServletRedirector.doPost(JSFUnitServletRedirector.java:46)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(ServletTestRedirector.java:72)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advice(ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedirector.java)
at org.jboss.jsfunit.framework.JSFUnitServletRedirector.doGet(JSFUnitServletRedirector.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.jsfunit.framework.JSFUnitFilter.doFilter(JSFUnitFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:109)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.basicauth.BasicProcessingFilter.doFilterHttp(BasicProcessingFilter.java:172)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:268)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at br.com.apta.seguranca.FiltroAutenticacao.doFilterHttp(FiltroAutenticacao.java:206)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.SessionFixationProtectionFilter.doFilterHttp(SessionFixationProtectionFilter.java:53)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Será que é por conta do spring-security?
att Davi Gomes da Costa
java.lang.NullPointerException
at org.jboss.jsfunit.jsfsession.JSFServerSession.getCurrentViewID(JSFServerSession.java:79)
at br.com.apta.test.ClienteMBTest.testInitialPage(ClienteMBTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(AbstractCactusTestCase.java:153)
at org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(AbstractWebTestCaller.java:119)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody0(AbstractWebTestController.java:93)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody1$advice(AbstractWebTestController.java:224)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest(AbstractWebTestController.java)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(ServletTestRedirector.java:101)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$advice(ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedirector.java)
at org.jboss.jsfunit.framework.JSFUnitServletRedirector.doPost(JSFUnitServletRedirector.java:46)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(ServletTestRedirector.java:72)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advice(ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedirector.java)
at org.jboss.jsfunit.framework.JSFUnitServletRedirector.doGet(JSFUnitServletRedirector.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.jsfunit.framework.JSFUnitFilter.doFilter(JSFUnitFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.providers.anonymous.AnonymousProcessingFilter.doFilterHttp(AnonymousProcessingFilter.java:105)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.rememberme.RememberMeProcessingFilter.doFilterHttp(RememberMeProcessingFilter.java:109)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.basicauth.BasicProcessingFilter.doFilterHttp(BasicProcessingFilter.java:172)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:268)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at br.com.apta.seguranca.FiltroAutenticacao.doFilterHttp(FiltroAutenticacao.java:206)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:87)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.ui.SessionFixationProtectionFilter.doFilterHttp(SessionFixationProtectionFilter.java:53)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:371)
at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:174)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Será que é por conta do spring-security?
att Davi Gomes da Costa
em 16/6/2011 14:17 - Responder
[Comentário do autor]
Sérgio Fantin
em 16/6/2011 18:11 - Responder
Sérgio Fantin
Olá Davi,
sugiro que você utilize o Maven para gerenciar o projeto, pois sem ele você perderá muito tempo pra configurar o projeto. Existem versões dependentes de jars incompatíveis.
Eu mesmo já tive muita dor de cabeça tentando configurar as bibliotecas na mão.
Abraços...
sugiro que você utilize o Maven para gerenciar o projeto, pois sem ele você perderá muito tempo pra configurar o projeto. Existem versões dependentes de jars incompatíveis.
Eu mesmo já tive muita dor de cabeça tentando configurar as bibliotecas na mão.
Abraços...
em 16/6/2011 18:11 - Responder
Ythalo Rossy Saldanha Lira
em 1/7/2011 11:23 - Responder
Caro Sérgio,
A figura 7 - Fases do ciclo de vida JSF está faltando.
Atenciosamente.
A figura 7 - Fases do ciclo de vida JSF está faltando.
Atenciosamente.
em 1/7/2011 11:23 - Responder
[Comentário do autor]
Sérgio Fantin
em 1/7/2011 18:16 - Responder
Sérgio Fantin
Olá Ythalo,
você diz que a figura está faltando aqui no site ou na revista?
Se for na revista, a figura está na página 63.
Abraços...
você diz que a figura está faltando aqui no site ou na revista?
Se for na revista, a figura está na página 63.
Abraços...
em 1/7/2011 18:16 - Responder
[Este post ainda não foi associado a uma sequência]
Você está em:
canal Java
Publicidade
Estudo comparativo entre banco de dados IBM Informix e Microsoft SQL
Sérgio Fantin
Space do autor
Bacharel em Informática pela UEM, e possui a certificação SCJP 6. É desenvolvedor Java e trabalha com JSF, EJB 3, JBoss, Maven, SCRUM, Ubuntu, etc. Seu blog em www.serjaum.wordpress.com contém vários tutoriais sobre JSF, Flex e desenvolvimento de software em geral.
Space do autor
0
0
