Ajax java.lang.IllegalStateException:CDATA标记不能嵌套

我在JSF页面中遇到了ajax请求问题。当我单击按钮时，我得到以下异常：

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)

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;

我认为

String

对象存在一些问题，因为当我硬编码站点上显示的JPA实体属性时，一切都正常。但是，当从数据库（PostgreSQL）检索实体时，它会抛出前面提到的异常

JSF代码：

<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>

阿克贾

在呈现JSF响应时，由于代码中的错误而引发异常。然而，Mojarra反过来未能使用内置的ajax异常处理程序正确处理此异常，导致了另一个异常，您现在看到的异常隐藏了原始异常的所有细节

仔细看看堆栈跟踪。从底部开始跟踪调用堆栈：

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

因此，它发生在渲染响应阶段。好的，看下一行（上面的那行）：

嘿，它已经通过了Mojarra的内置ajax异常处理程序

AjaxExceptionHandlerImpl

！这仅在ajax请求期间发生异常时调用。好的，从下到上阅读下面几行：

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)

因此，它试图将错误信息写入ajax响应。此信息必须放在CDATA块中。但是，启动CDATA块失败，原因如下，因为显然已经有一个CDATA块打开：

java.lang.IllegalStateException: CDATA tags may not nest

这反过来表明在编写ajax响应期间发生了异常，很可能是因为您正在一个getter方法中执行业务逻辑，该方法仅在生成HTML输出期间调用。因此，过程很可能如下所示：

JSF进入RENDER_响应阶段

JSF需要生成HTML输出

对于每一个

（或

），它都需要创建一个

XML块，并将生成的HTML输出放在内部（以保持XML输出在语法上有效）。因此，需要启动CDATA块

在将HTML输出生成CDATA块时，将计算所有渲染时EL表达式，包括所有UI组件的

value

属性

在某个地方，EL表达式背后的getter抛出了一个由您自己的代码中的bug引起的异常

JSF立即停止生成HTML输出，并且没有关闭CDATA块。HTTP响应包含不完整的数据

AjaxExceptionHandlerImpl

被触发

AjaxExceptionHandlerImpl

需要将异常/错误详细信息写入响应。但是，它没有检查响应是否已经写入。它盲目地试图打开CDATA块，而CDATA块又失败了，因为它已经打开了。它抛出了您看到的异常，隐藏了它试图处理的真正底层异常的所有细节

如您所见，问题有两个方面：

JSF渲染器不应该让响应半生不熟

Mojarra的AjaxExceptionHandlerImpl应该已经检查/验证了响应的状态

---

如果将Mojarra的内置ajax异常处理程序替换为，或，那么它将最终揭示并显示由代码中的错误导致的真正底层。如前所述，它很可能是由以下原因引起的。

CDATA问题不是PrimeFaces问题，而是与负责提供部分输出的JSF实现有关。

---

替换为它的JSF属性；）

如果您还看到服务器日志中的

java.lang.ClassCastException:com.sun.faces.facelets.compiler.ui指令无法强制转换为org.primefaces.component.tree.UITreeNode

，请添加

<context-param>
  <param-name>javax.faces.FACELETS_SKIP_COMMENTS</param-name>
  <param-value>true</param-value>
</context-param>

javax.faces.FACELETS\u跳过\u注释
符合事实的

---

<> > <代码> /WebINF/Web.XML/Cux>

< P>。p> 例如，如果忘记在xhtml页面正在使用的某个bean中初始化ArrayList，有时会收到相同的错误消息：

我会这样做：

List<String> myList;

---

因此，另一件需要考虑的事情是，确保您已经完成了所有的内务管理（确保变量被初始化/填充，等等）

我在Tomcat7中摆脱simliar执行选项的经验是：如果您在jsf中调用一个方法，您必须添加（），即使它没有参数

如果您使用的是jetty，则不会出现此异常

编辑：尽管此异常已被消除，但仍出现另一个异常：

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)

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;

在研究之后，我发现Tomcat7本身带来了EL依赖，因此pom.xml中的任何其他依赖都像

<dependency>
    <groupId>javax.el</groupId>
    <artifactId>el-api</artifactId>
    <version>2.2</version>
    <scope>provided</scope>
</dependency>

javax.el
埃尔api
2.2
假如

应将其移除，以避免混合

之后，您必须在Eclipse中以-

tomcat7:Run

的方式启动tomcat7，而不是默认启动Tomcat6的

tomcat:Run

我的环境：

• 日食开普勒
• JDK 1.7.0_45
• Maven 3.1.1

---

我遇到了与您相同的问题，当我使用来自支持bean的autocomplete组件进行绑定时，它工作得很好

<p:autoComplete id="autocomplete" binding="#{searchBean.compui}" title="Find" value="#{searchBean.searchfor}" forceSelection="false" queryDelay="30" dropdown="true" maxResults="20" emptyMessage="None" completeMethod="#{searchBean.complete}" style="width: 90%;"/>
<p:commandButton id="cmdsearch" value="#{msg.search}" action="#{searchBean.search}" update="tblprocresults" icon="ui-icon-zoomin"/>

---

我猜你的问题在JSf代码的其他地方，而不是你发布的片段中。-1那么，解决方案是什么？我们应该如何防止发生此异常？我遇到了这个例外，不知道你的答案会有什么帮助，除非你对JSF内部进行了修改，这对我来说是完全无用的，我想大多数开发人员只是想修复一个bug。您非常不清楚....@St.Antario：我在答案的顶部添加了一个tldr来表示不耐烦。好的，问题是当我们使用JSF 1.2时，代码运行良好。在更新到JSF2.1之后，它开始抛出这个异常。这是一个严重的JSF2.x问题吗？不需要初始化compui（自动完成绑定组件）

private AutoComplete compui;
//compui is initialized when bean is constructed
    public AutoComplete getCompui() {
            return compui;
        }

        public void setCompui(AutoComplete compui) {
            this.compui = compui;
        }