java.lang.IllegalStateException: las tags CDATA no pueden anidar

Tengo un problema con una solicitud de Ajax en una página JSF. Cuando hago clic en el botón, obtengo esta excepción:

SEVERE: Servlet.service() for servlet Faces Servlet threw exception java.lang.IllegalStateException: CDATA tags may not nest at com.sun.faces.renderkit.html_basic.HtmlResponseWriter.startCDATA(HtmlResponseWriter.java:630) at javax.faces.context.ResponseWriterWrapper.startCDATA(ResponseWriterWrapper.java:172) at javax.faces.context.PartialResponseWriter.startError(PartialResponseWriter.java:342) at org.primefaces.context.PrimePartialResponseWriter.startError(PrimePartialResponseWriter.java:210) at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:200) at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:123) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) 

Creo que es un problema con los objetos String , porque cuando codigo las propiedades de la entidad JPA que se muestran en el sitio, todo está bien. Sin embargo, cuando la entidad se recupera de la base de datos (PostgreSQL), arroja la excepción antes mencionada.

Código JSF:

 

Akcja

Se produce una excepción durante el procesamiento de la respuesta JSF causada por un error en su código. Sin embargo, Mojarra a su vez no manejó adecuadamente esta excepción con el controlador de excepción incorporado ajax, lo que ocasionó otra excepción que ahora está viendo, ocultando todos los detalles sobre la excepción original.

Mire más de cerca el rastro de la stack. Comience en la parte inferior para seguir la stack de llamadas:

 at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) 

Por lo tanto, sucedió durante la fase de respuesta de renderizado. De acuerdo, mira la siguiente línea (la que está arriba):

 at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:123) 

¡Oye, ha pasado a través del manejador de excepciones AjaxExceptionHandlerImpl ! Esto solo se invoca cuando se produce una excepción durante una solicitud de Ajax. De acuerdo, lea las siguientes líneas más allá de abajo hacia arriba:

 at com.sun.faces.renderkit.html_basic.HtmlResponseWriter.startCDATA(HtmlResponseWriter.java:630) at javax.faces.context.ResponseWriterWrapper.startCDATA(ResponseWriterWrapper.java:172) at javax.faces.context.PartialResponseWriter.startError(PartialResponseWriter.java:342) at org.primefaces.context.PrimePartialResponseWriter.startError(PrimePartialResponseWriter.java:210) at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:200) 

De este modo, intenta escribir la información de error en la respuesta ajax. Esta información tiene que ir en un bloque CDATA. Sin embargo, iniciar un bloque CDATA falló de la siguiente manera porque aparentemente ya hay un bloque CDATA abierto:

 java.lang.IllegalStateException: CDATA tags may not nest 

Esto, a su vez, indica que la excepción se produjo durante la redacción de la respuesta ajax, muy probablemente porque está realizando una lógica comercial en un método getter que solo se invoca durante la generación del resultado HTML. Entonces, el proceso fue más probable de la siguiente manera:

  1. JSF entra en la fase RENDER_RESPONSE.
  2. JSF necesita generar salida HTML.
  3. Por cada (o ), necesita crear un bloque XML con el resultado HTML generado dentro de un bloque CDATA (para mantener la salida XML sintácticamente válida). Entonces, se debe iniciar un bloque CDATA.
  4. Al generar el resultado HTML en un bloque CDATA, se evalúan todas las expresiones EL de tiempo de renderización, incluido el atributo de value de todos los componentes UI.
  5. En algún lugar, el getter detrás de la expresión EL arrojó una excepción causada por un error en su propio código.
  6. JSF detuvo inmediatamente la generación de salida HTML y no cerró el bloque CDATA. La respuesta HTTP contiene datos halfbaked.
  7. AjaxExceptionHandlerImpl se activa.
  8. AjaxExceptionHandlerImpl necesita escribir los detalles de la excepción / error en la respuesta. Sin embargo, no verificó si la respuesta ya está escrita. Intenta ciegamente abrir un bloque CDATA que a su vez falló porque ya está abierto. Emitió la excepción que está viendo, ocultando todos los detalles sobre la verdadera excepción subyacente que trató de manejar.

Como puede ver, el problema es doble:

  1. El procesador de JSF no debería haber dejado la respuesta medio cocida.
  2. AjaxExceptionHandlerImpl de Mojarra debería haber verificado / verificado el estado de la respuesta.

Si reemplaza el controlador de excepción incorporado ajax de Mojarra por uno personalizado que imprime inmediatamente el seguimiento de la stack , o por OmniFaces FullAjaxExceptionHandler que es capaz de detectar y limpiar las respuestas ajax medio cocidas , entonces finalmente revelará y mostrará el subyacente real causado por un error en su código. Como se dijo anteriormente, lo más probable es que se deba a la lógica de negocios en un método getter, que es una mala práctica .

Tuve el mismo problema que el tuyo. Cuando utilicé el enlace con el componente autocompletar del bean de respaldo funcionó bien.

   

y en el grano de respaldo

 private AutoComplete compui; //compui is initialized when bean is constructed public AutoComplete getCompui() { return compui; } public void setCompui(AutoComplete compui) { this.compui = compui; } 

El problema de CDATA no es una cuestión de PrimeFaces, sino que está relacionada con la implementación de JSF, que es responsable de proporcionar el resultado parcial. reemplazar por su propiedad JSF;)

Si también ves java.lang.ClassCastException: com.sun.faces.facelets.compiler.UIInstructions cannot be cast to org.primefaces.component.tree.UITreeNode en el registro del servidor, agrega

  javax.faces.FACELETS_SKIP_COMMENTS true  

a /WEB-INF/web.xml

Solo para incluir algo que considerar también, a veces puede ser un error realmente desquiciado.

Por ejemplo, a veces recibo este mismo mensaje de error si olvidé inicializar una ArrayList en uno de mis beans que está usando la página xhtml:

Yo haría esto:

 List myList; 

Pero olvídate de hacer esto:

 myList = new ArrayList(); 

Así que, como otra cosa en qué pensar, asegúrese de que se ha ocupado de todas sus tareas domésticas (asegurándose de que las variables estén inicializadas / pobladas, etc.).

Mi experiencia para deshacerme de una excepción similar en Tomcat 7 es: si estás llamando a un método en jsf, deberás agregar (), incluso si no tiene un parámetro.

Esta excepción, pero no aparecerá, si está utilizando embarcadero

EDITAR: Aunque esta excepción se eliminó, dio otra excepción:

 java.lang.NoSuchMethodError: javax.el.ELResolver.invoke(Ljavax/el/ELContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object; 

Después de investigar descubrí que el Tomcat 7 trae la dependencia EL por sí mismo, por lo que cualquier otra dependencia en el pom.xml

  javax.el el-api 2.2 provided  

Debería eliminarse para evitar la mezcla.

Después de eso, debe iniciar el tomcat7 por Ejecutar como – tomcat7:run en Eclipse, en lugar de tomcat:run que inicia de forma predeterminada el tomcat 6.

Mi entorno:

  • Eclipse Kepler
  • JDK 1.7.0_45
  • Maven 3.1.1