Faces Servlet jogou java.lang.StackOverflowError exceção

Question

Ok, Já corri em toda a minha primeira StackOverflowError desde que entrou neste site, eu percebi que este é um deve postar :-). O meu ambiente é Seam 2.0.1.GA, JBoss 4.2.2.GA e eu estou usando JSF. Eu estou no processo de conversão de um facelets ver a JSP para tirar partido de algumas tags JSP existentes utilizadas no nosso site existente. Mudei o faces-config.xml e os arquivos de configuração web.xml e começou a receber o seguinte erro ao tentar processar uma página jsp. Alguém tem alguma ideia?

2008-09-17 09: 45: 17,537 DEBUG [Org.jboss.seam.contexts.FacesLifecycle] Comece pedido JSF para /form_home.jsp 2008-09-17 09: 45: 17,587 ERROR [Org.apache.catalina.core.ContainerBase. [Jboss.web]. [Localhost]. [/]. [Faces Servlet]] Servlet.service () para servlet Faces Servlet jogou exceção java.lang.StackOverflowError em org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:210) em org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222) em org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222) em org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222) ...

Meu arquivo faces-config.xml está agora vazia, sem FaceletsViewHandler:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xi="http://www.w3.org/2001/XInclude"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee  
   http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">

</faces-config>

E o meu arquivo web.xml:

<?xml version="1.0"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
  http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
 <!-- Ajax4jsf -->
 <context-param>
  <param-name>org.richfaces.SKIN</param-name>
  <param-value>blueSky</param-value>
 </context-param>
  <!-- Seam -->
 <listener>
  <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
 </listener>


 <filter>
  <filter-name>Seam Filter</filter-name>
  <filter-class>org.jboss.seam.servlet.SeamFilter</filter-class>
 </filter>

 <filter-mapping>
  <filter-name>Seam Filter</filter-name>
  <url-pattern>*.jsp</url-pattern>
 </filter-mapping>

 <servlet>
    <servlet-name>Seam Resource Servlet</servlet-name>
     <servlet-class>org.jboss.seam.servlet.SeamResourceServlet
     </servlet-class>
 </servlet>
 <servlet-mapping>
   <servlet-name>Seam Resource Servlet</servlet-name>
   <url-pattern>/seam/resource/*</url-pattern>
 </servlet-mapping>
 <!-- Seam end --> 

 <!-- JSF -->
 <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.jsp</param-value>
 </context-param>

 <servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
 </servlet>
 <servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsp</url-pattern> 
 </servlet-mapping>

Answer 1

Eu era capaz de descobrir este problema. Aparentemente, não é possível configurar web.xml ter o mesmo param-value de .jsp para Javax.faces.DEFAULT_SUFFIX como o Faces Servlet url-pattern (* .jsp). Se você mudar de url-padrão para .jspx ou / whateverdirnameyouwant / o aplicativo é iniciado sem erros de estouro de pilha. (Nota: a chave é que DEFAULT_SUFFIX e Faces Servlet url-padrão não pode ser o mesmo, independentemente do que eles são.) Espero que isso ajude alguém que enfrenta esse problema específico

.

Answer 2

Stack transborda em java são quase sempre causados ??por chamadas de recursão / método infinitas. No seu caso, dado o rastreamento de pilha, parece 'getAttribute ()' está sendo chamado repetidamente até acidente. Enquanto eu não sou muito familiarizado com os ambientes particulares que você está usando, gostaria de sugerir a verificação de seu código JSP para qualquer deste tipo de comportamento (por exemplo, dois métodos que chamam uns aos outros)

Answer 3

Então, eu tive um erro semelhante. Para mim, foi que eu tinha um projeto JSF e eu estava brincando com as extensões de arquivo. Para começar, eu tinha todos os meus arquivos na web com a extensão .jsp. Este foi trabalhar, mas então eu queria que eles fossem todos .JSF, em seguida, depois que eu fui all-in no utilizando .xhtml. No processo, o meu arquivo web.xml alterado para acomodar xhtml e jsf. Alterar o arquivo web.xml estava bem. O que me levou a StackOverflowError era que eu tinha index.xhtml com uma tag ui.include apontando para header.jsf. Então, eu tinha um apontador arquivo xhtml para um arquivo jsf. Eu tinha pensado que web.xml seria capaz de lidar com isso, mas isso não aconteceu, eu tenho o StackOverflowError. Assim, para corrigir isso, agora todos os meus arquivos JSF tem .xhtml extensão, e ui aninhada:. Incluir tags apontam para arquivos .xhtml

Por outro lado, porém, a url do navegador pode lidar com o index.jsp, index.jsf, index.xhtml muito bem. Assim, o web.xml (com mapeamentos de servlet para JSP, JSF e XHTML) lida com a url do navegador muito bem, mas não para o meu problema acima destacado.