ajax - java.lang.IllegalStateException: CDATA tags may not nest

Question

I've got a problem with an ajax request in a JSF page. When I click on the button, I get this exception:

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)

I think it's some problem with String objects, because when I hardcode the JPA entity properties which are shown on the site, then everything is OK. However when the entity is retrieved from the database (PostgreSQL), it throws the aforementioned exception.

JSF code:

<p:column>
    <f:facet name="header">
        Akcja
    </f:facet>
    <h:commandButton actionListener="#{mBDocumentMigration.actionEdit(object)}" value="Edytuj" rendered="#{mBDocumentMigration.editingObject == null}" >
        <f:ajax render="@form" execute="@form" />
    </h:commandButton>
    <h:commandButton action="#{mBDocumentMigration.actionZapisz}" value="Zapisz" rendered="#{mBDocumentMigration.editingObject != null}" >
    <f:ajax render="@form"  execute="@this" />
    </h:commandButton>
</p:column>

Answer 1

There's an exception being thrown during rendering the JSF response caused by a bug in your code. However, Mojarra in turn failed to properly handle this exception with the builtin ajax exception handler, causing another exception which you're now seeing, hiding away all detail about the original exception.

Look closer at the stack trace. Start at the bottom to track the call stack:

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

Thus, it happened during render response phase. Okay, look at the next line (the one above it):

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

Hey, it's been passed through Mojarra's builtin ajax exception handler AjaxExceptionHandlerImpl! This is only invoked when an exception has occurred during an ajax request. Okay, read the next lines further from bottom to top:

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)

It's thus attempting to write the error information to the ajax response. This information has to go in a CDATA block. However, starting a CDATA block failed as follows because there's apparently already a CDATA block open:

java.lang.IllegalStateException: CDATA tags may not nest

This in turn indicates that the exception occurred during writing the ajax response, most likely because you're performing business logic in a getter method which is only invoked during generating the HTML output. So the process was most likely as follows:

1. JSF enters RENDER_RESPONSE phase.
2. JSF needs to generate HTML output.
3. For every <f:ajax render="some"> (or <p:ajax update="some">), it needs to create a <update id="some"> XML block with the generated HTML output inside a CDATA block (to keep the XML output syntactically valid). So a CDATA block needs to be started.
4. While generating the HTML output into a CDATA block, all render-time EL expressions are evaluated, including value attribute of all UI components.
5. Somewhere, the getter behind the EL expression threw an exception caused by a bug in your own code.
6. JSF promptly stopped generating HTML output and didn't close the CDATA block. The HTTP response contains halfbaked data.
7. AjaxExceptionHandlerImpl is triggered.
8. AjaxExceptionHandlerImpl needs to write the exception/error detail to the response. However, it didn't check if the response is already written. It blindly attempts to open a CDATA block which in turn failed because it's already opened. It threw the exception you're seeing, hiding away all detail about the real underlying exception it tried to handle.

As you can see, the problem is two-fold:

1. JSF renderer should not have left the response halfbaked.
2. Mojarra's AjaxExceptionHandlerImpl should have checked/verified the state of the response.

If you replace Mojarra's builtin ajax exception handler by a custom one which immediately prints the stack trace, or by OmniFaces FullAjaxExceptionHandler which is capable of detecting and cleaning halfbaked ajax responses, then it will finally reveal and show the real underlying caused by a bug in your code. As said before, it's most likely caused by performing business logic in a getter method, which is a bad practice.