Faces Servlet a lancé une exception java.lang.StackOverflowError

Question

D'accord, j'ai rencontré mon premier StackOverflowError depuis que j'ai rejoint ce site. J'ai pensé que c'était un article à ne pas manquer :-). Mon environnement est Seam 2.0.1.GA, JBoss 4.2.2.GA et j'utilise JSF. Je suis en train de convertir une vue facelets en JSP pour tirer parti de certaines balises JSP existantes utilisées sur notre site existant. J'ai changé les fichiers de configuration faces-config.xml et web.xml et j'ai commencé à recevoir l'erreur suivante lors de la tentative de rendu d'une page jsp. Quelqu'un a des idées?

  

2008-09-17 09: 45: 17,537 DEBUG   [org.jboss.seam.contexts.FacesLifecycle]   Lancer la requête JSF pour /form_home.jsp   2008-09-17 09: 45: 17,587 ERREUR   [org.apache.catalina.core.ContainerBase. [jboss.web]. [hôte local]. [/]. [Visages   Servlet]] Servlet.service () pour   servlet Faces Servlet a jeté une exception   java.lang.StackOverflowError            à org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:210)            à org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222)            à org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222)            à org.apache.catalina.core.ApplicationHttpRequest.getAttribute (ApplicationHttpRequest.java:222)            ...

Mon fichier faces-config.xml est maintenant vide sans 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>

Et mon fichier 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

J'ai pu résoudre ce problème. Apparemment, vous ne pouvez pas configurer web.xml pour que la même valeur param de .jsp pour Javax.faces.DEFAULT_SUFFIX soit identique au motif url de servlet de visages (* .jsp). Si vous modifiez votre modèle d'URL en .jspx ou en / quel que soit le nom de votre nom / , l'application démarre sans erreur de débordement de pile. (Remarque: la clé est que DEFAULT_SUFFIX et le modèle d'URL de Servlet Faces ne peuvent pas être identiques, peu importe ce qu'ils sont.) J'espère que cela aidera toute autre personne rencontrant ce problème spécifique.

Answer 2

Les débordements de pile en Java sont presque toujours causés par des appels de méthode / récursion infinis. Dans votre cas, étant donné la trace de la pile, il apparaît que "getAttribute ()" est appelé à plusieurs reprises jusqu'à ce que crash. Bien que je ne connaisse pas très bien les environnements particuliers que vous utilisez, je vous suggère de vérifier votre code .jsp pour tout comportement de ce type (par exemple, deux méthodes qui s'appellent l'une l'autre)

Answer 3

Donc, j'ai eu une erreur similaire. Pour moi, c’était que j’avais un projet JSF et que j’étais en train de jouer avec les extensions de fichiers. Pour commencer, j'avais tous mes fichiers Web avec l'extension .jsp. Cela fonctionnait, mais je voulais ensuite qu’ils soient tous .jsf, puis je me suis mis à utiliser .xhtml. Au cours du processus, mon fichier web.xml a été modifié pour accueillir xhtml et jsf. Changer le fichier web.xml s'est bien passé. Ce qui m'a valu le StackOverflowError, c'est que j'avais index.xhtml avec une balise ui.include pointant vers header.jsf. J'ai donc eu un fichier xhtml pointant vers un fichier jsf. J'avais pensé que web.xml serait capable de gérer ça, mais ça n'a pas été le cas, j'ai eu StackOverflowError. Donc, pour résoudre ce problème, tous mes fichiers JSF ont maintenant une extension .xhtml et les balises imbriquées ui: include pointent vers des fichiers .xhtml.

D'un autre côté, l'URL du navigateur peut gérer les fichiers index.jsp, index.jsf, index.xhtml. Ainsi, le fichier web.xml (avec les mappages de servlets pour jsp, jsf et xhtml) gère très bien l’URL du navigateur, mais pas pour ce que mon problème a souligné.