java.lang.IllegalStateException: CDATA tags may not nest

by

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.

More Related Contents:

  1. How to find out client ID of component for ajax update/render? Cannot find component with expression “foo” referenced from “bar”
  2. How can I populate a text field using PrimeFaces AJAX after validation errors occur?
  3. Keep p:dialog open when a validation error occurs after submit
  4. How to exclude child component in ajax update of a parent component?
  5. Add additional parameter to JSF Ajax event listener
  6. Can you update an h:outputLabel from a p:ajax listener?
  7. How to decrease request payload of p:ajax during e.g. p:dataTable pagination
  8. List of events
  9. selectOneMenu ajax events
  10. Conditionally provide either file download or show export validation error message
  11. Ajax update and submission using h:commandButton
  12. How to invoke a JSF managed bean on a HTML DOM event using native JavaScript?
  13. UIForm with prependId=”false” breaks
  14. When to use valueChangeListener or f:ajax listener?
  15. Session timeout and ViewExpiredException handling on JSF/PrimeFaces ajax request
  16. What values can I pass to the event attribute of the f:ajax tag?
  17. Exception handling in JSF ajax requests
  18. Rendering other form by ajax causes its view state to be lost, how do I add this back?
  19. Form submit in conditionally rendered component is not processed
  20. Process onclick function after ajax call
  21. How to pass parameter to f:ajax in h:inputText? f:param does not work
  22. ICEfaces libary in classpath prevents Save As dialog from popping up on file download
  23. Render multiple components with f:ajax
  24. How can I get browser to prompt to save password?
  25. What security risks exist when setting Access-Control-Allow-Origin to accept all domains?
  26. Unicode input retrieved via PrimeFaces input components become corrupted
  27. How to make a SPA SEO crawlable?
  28. Defer loading and parsing of PrimeFaces JavaScript files
  29. How to Implement ajax pagination with will_paginate gem
  30. Selenium WebDriver – determine if element is clickable (i.e. not obscured by dojo modal lightbox)

Leave a Comment