java.lang.IllegalStateException: CDATA-Tags können möglicherweise nicht verschachtelt werden

Ich habe ein problem mit einem ajax-request in einer JSF-Seite. Wenn ich auf den button, erhalte ich diese 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)

Ich denke, dass es einige problem mit String Objekte, denn wenn ich fest die JPA-Entität-Eigenschaften, welche auf der Website dargestellt sind, dann ist alles OK. Allerdings, wenn die Entität aus der Datenbank abgerufen werden (PostgreSQL), wirft es die oben erwähnten Ausnahme.

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>

InformationsquelleAutor der Frage alinoe | 2012-08-10

44

Gibt es eine Ausnahme ausgelöst wird, während rendering JSF-Antwort, verursacht durch einen Fehler in Ihrem code. Allerdings Mojarra wiederum konnte nicht richtig verarbeitet diese Ausnahme mit der eingebauten ajax-Ausnahme-handler, wodurch eine weitere Ausnahme, die Sie jetzt sehen, verstecken sich alle Details über die ursprüngliche Ausnahme.

Schauen Sie näher an die stack-trace. Starten Sie am unteren Rand verfolgen des call-Stacks:
```
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
```
So geschah es während der render-response-phase. Okay, sehen Sie in der nächsten Zeile (oben):
```
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:123)
```
Hey, es ist weitergegeben worden durch Mojarra s eingebaute ajax-Ausnahme-handler AjaxExceptionHandlerImpl! Dies ist nur aufgerufen, wenn eine Ausnahme aufgetreten ist, während einer ajax-Anfrage. Okay, Lesen Sie die nächsten Zeilen weiter von unten nach oben:
```
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)
```
Es ist also zu schreiben versucht die Fehlerinformationen an die ajax-Antwort. Diese Informationen gehen in einem CDATA-block. Allerdings, ab einem CDATA-block scheiterten Sie wie folgt vor, weil es anscheinend schon einen CDATA-block öffnen:
```
java.lang.IllegalStateException: CDATA tags may not nest
```
Dies wiederum bedeutet, dass die Ausnahme aufgetreten ist beim schreiben der ajax-Antwort, wahrscheinlich weil Sie gerade ausführen von business Logik in einer getter-Methode, die nur aufgerufen wird, während die Erzeugung der HTML-Ausgabe. So wurde der Prozess wahrscheinlich wie folgt:
1. JSF betritt RENDER_RESPONSE phase.
2. JSF zum generieren der HTML-Ausgabe.
3. Für jeden <f:ajax render="some"> (oder <p:ajax update="some">), die es braucht, um erstellen Sie eine <update id="some"> XML-block mit der generierten HTML-Ausgabe innerhalb eines CDATA-block (halten die XML-Ausgabe syntaktisch gültig ist). So ein CDATA-block gestartet werden muss.
4. Beim generieren der HTML-Ausgabe in einem CDATA-block, alle render-Zeit, die EL-Ausdrücke werden ausgewertet, einschließlich value - Attribut aller UI-Komponenten.
5. Irgendwo, die getter hinter dem EL-Ausdruck hat eine Ausnahme verursacht durch einen Fehler in Ihrem eigenen code.
6. JSF umgehend gestoppt generieren der HTML-Ausgabe und nicht in der Nähe der CDATA-block. Die HTTP-Antwort enthält halfbaked Daten.
7. AjaxExceptionHandlerImpl ausgelöst wird.
8. AjaxExceptionHandlerImpl schreiben muss die Ausnahme/Fehler detail auf die Antwort. Es dauerte aber nicht überprüfen, ob die Antwort bereits geschrieben. Es blindlings versucht zu öffnen ein CDATA-block, was wiederum scheiterte, weil er bereits geöffnet. Er warf der Ausnahme, dass Sie sehen, verstecken sich alle Details über die wahre zugrunde liegende Ausnahme, es versucht zu verarbeiten.
Wie Sie sehen können, das problem ist zweifach:
1. JSF-renderer sollte nicht verlassen haben, die Antwort halfbaked.
2. Mojarra s AjaxExceptionHandlerImpl sollte geprüft/überprüft den Status der Antwort.
Wenn Sie ersetzen Mojarra s eingebaute ajax-Ausnahme-handler, die durch einen Brauch man die sofort-Drucke der stack-traceoder durch OmniFaces FullAjaxExceptionHandlerdie in der Lage zu erkennen und die Reinigung von halfbaked ajax-Antwortendann wird es letztendlich zeigen und zeigen das wahre zugrunde, verursacht durch einen Fehler in Ihrem code. Wie gesagt, es ist wahrscheinlich durch Durchführung von business-Logik in einer getter-Methode, die eine schlechte Praxis.

InformationsquelleAutor der Antwort BalusC

Ich hatte das gleiche problem wie deins, Wenn ich in der Bindung mit autocomplete-Komponente aus der backing-bean funktionierte es gut.

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

und in der backing-bean

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

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

InformationsquelleAutor der Antwort MTom

-2

CDATA Problem nicht PrimeFaces Frage, aber mit JSF-Implementierung wer ist verantwortlich für die Bereitstellung der partielle Ausgabe.
ersetzen Sie durch den JSF-Eigenschaft 😉

InformationsquelleAutor der Antwort REDA
-2

Wenn Sie auch sehen java.lang.ClassCastException: com.sun.faces.facelets.compiler.UIInstructions cannot be cast to org.primefaces.component.tree.UITreeNode im server-log, add
```
<context-param>
  <param-name>javax.faces.FACELETS_SKIP_COMMENTS</param-name>
  <param-value>true</param-value>
</context-param>
```
zu /WEB-INF/web.xml

InformationsquelleAutor der Antwort Karl Richter
-2

Nur zu werfen, in etwas, das auch zu betrachten, manchmal kann es einem wirklich die Knochen-Leitung-Fehler.

Zum Beispiel, manchmal würde ich die gleiche Fehlermeldung, wenn ich vergessen habe zu initialisieren einer ArrayList in eine von meinen Bohnen, dass die xhtml-Seite verwendet wird:

Ich würde dies tun:
```
List<String> myList;
```
Aber vergessen, dies zu tun:
```
myList = new ArrayList();
```
Also nur als eine andere Sache zu denken, stellen Sie sicher, Sie haben aufgepasst, dass alle Ihre Hauswirtschaft (sicherstellen, dass Variablen initialisiert werden/aufgefüllt, etc...)

InformationsquelleAutor der Antwort Eagle's Nest
-4

Meine Erfahrung, um loszuwerden, ein simliar execption in Tomcat 7 ist: wenn Sie eine Methode aufrufen, die in jsf, müssen Sie auf "hinzufügen" (), auch wenn es keinen parameter.

Diese Ausnahme aber wird nicht angezeigt, wenn Sie mit jetty

EDIT: Auch wenn diese Ausnahme gestrichen wurde, gab es noch eine Ausnahme:
```
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;
```
Nach einiger recherche fand ich den Tomcat 7 bringt EL Abhängigkeit von selbst, daher ist jede andere Abhängigkeit in der pom.xml wie
```
<dependency>
    <groupId>javax.el</groupId>
    <artifactId>el-api</artifactId>
    <version>2.2</version>
    <scope>provided</scope>
</dependency>
```
sollte entfernt werden, um zu vermeiden, das mischen.

Danach starten Sie die tomcat7 von Run as - tomcat7:run in Eclipse statt tomcat:run beginnt standardmäßig tomcat 6.

Meine Umgebung:
- Eclipse Kepler
- JDK 1.7.0_45
- Maven 3.1.1
InformationsquelleAutor der Antwort user3778446

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.