Pregunta

Ok, me he encontrado a través de mi primer StackOverflowError desde que se unió a este sitio, pensé que esto es un post :-).Mi entorno es la Costura 2.0.1.GA, JBoss 4.2.2.GA y estoy usando JSF.Estoy en el proceso de conversión de un facelets ver a JSP para tomar ventaja de algunos de los actuales JSP etiquetas utilizadas en nuestro sitio.He cambiado el faces-config.xml y el web.xml los archivos de configuración y comenzó a recibir el siguiente mensaje de error al intentar procesar una página jsp.Alguien tiene alguna idea?

2008-09-17 09:45:17,537 de DEPURACIÓN [org.jboss.la costura.los contextos.FacesLifecycle] Comenzar a petición de JSF para /form_home.jsp 2008-09-17 09:45:17,587 ERROR [org.apache.catalina.núcleo.ContainerBase.[jboss.web].[localhost].[/].[Rostros Servlet]] Servlet.(servicio) para servlet Faces Servlet tiró excepción java.lang.StackOverflowError en org.apache.catalina.núcleo.ApplicationHttpRequest.getAttribute(ApplicationHttpRequest.java:210) en org.apache.catalina.núcleo.ApplicationHttpRequest.getAttribute(ApplicationHttpRequest.java:222) en org.apache.catalina.núcleo.ApplicationHttpRequest.getAttribute(ApplicationHttpRequest.java:222) en org.apache.catalina.núcleo.ApplicationHttpRequest.getAttribute(ApplicationHttpRequest.java:222) ...

Mi faces-config.xml archivo ahora está vacía sin 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>

Y mi Web.xml archivo:

<?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>
¿Fue útil?

Solución

Yo era capaz de entender este problema.Al parecer no se puede configurar web.xml para tener el mismo param-value de .jsp para Javax.las caras.DEFAULT_SUFFIX como las Caras Servlet url-pattern (*.jsp).Si usted cambia su dirección url-pattern para .jspx o a /whateverdirnameyouwant/ la aplicación comienza con ningún desbordamiento de la pila de errores.(nota:la clave es que DEFAULT_SUFFIX y Faces Servlet url-pattern no puede ser el mismo independientemente de lo que son.) Espero que esto ayuda a cualquier persona que experimenta este problema específico.

Otros consejos

Desbordamientos de pila en java son casi siempre causados por la recursividad infinita / llamadas de método.En su caso, el seguimiento de la pila, aparece 'getAttribute()' se llama repetidamente hasta que se bloquee.Mientras yo no estoy íntimamente familiarizado con los entornos particulares que usted está utilizando, sugiero que lo consultes tu .código jsp para cualquiera de este tipo de comportamiento (por ejemplo, dos métodos que llaman el uno al otro)

Por lo tanto, tuve un error similar.Para mí, era que tenía un proyecto JSF y yo jugueteaba con las extensiones de archivo.Para empezar, yo tenía todos mis archivos web con la extensión .jsp.Esto fue a trabajar, pero entonces yo quería ser la de todos .jsf, a continuación, después de que salieron a por todas en el uso .xhtml.En el proceso, mi web.xml archivo modificado para acomodar xhtml y jsf.El cambio de la web.xml archivo estaba bien.Lo que me StackOverflowError fue que me había de índice.xhtml con una interfaz de usuario.incluyen la etiqueta apuntando a la cabecera.jsf.Así que yo tenía xhtml archivo que apunta a un archivo jsf.Yo había pensado que web.xml sería capaz de manejar esto, pero no se, tengo la StackOverflowError.Así que, para solucionar este problema, ahora todos mis JSF archivos tienen la extensión .xhtml, y anidado de interfaz de usuario:se incluyen las etiquetas de punto .archivos xhtml.

En la otra cara de la moneda, sin embargo, la url del navegador puede manejar el índice.jsp, el índice.jsf, el índice.xhtml bien.Por lo que el web.xml (con servlet asignaciones para jsp, jsf y xhtml) se encarga de la url del navegador bien, pero no por lo que mi problema anterior destacó.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top