Hi, I have a question on a (strange?) behavior with JSP:TEXT. Imagine, you have the following JSP(X) file:
<?xml version="1.0" encoding="UTF-8" ?> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"; version="2.0" xmlns:f="http://java.sun.com/jsf/core"; xmlns:h="http://java.sun.com/jsf/html"; xmlns:tr="http://myfaces.apache.org/trinidad";> <jsp:text><![CDATA[<?xml version="1.0" encoding="UTF-8" ?>]]></jsp:text> <f:view> <tr:document ....> ... </tr:document> </f:view> </jsp:root> This JSPX has a <jsp:text>, which adds a XML PI to the outputstream, to be rendered by the JSP engine. However, this has some problems with the Trinidad Ajax facility, which itself provides a PPRResponseWriter (see [1]), which itself decorates the XmlResponseWriter (see [2]). Now, when Trinidad renders out the "updates" for the PPR postback, calling startDocument() on the PPRResponseWriter renders out this: <?xml version="1.0" ?> <=== from XmlResponseWriter <?Tr-XHR-Response-Type ?> <=== from PPRResponseWriter .....more.....content....here..... So far so good,... but since the <jsp:text /> is present in the jsp(x) file, the JSP engine add an "extra" XML PI (in this example the <?xml version="1.0" encoding="UTF-8" ?>) So the end result, what is sent down to the client, looks like: <?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" ?> <?Tr-XHR-Response-Type ?> These two XML PIs used to confuse Trinidad (fixed in 1.x.9, by doing a simple "window.location.reload(true);"). (see [3]). Now the page works, but there is an extra round trip.. I wonder if there is a *safe* way to "reset" the underlying writer ?? BTW. the main bug was reported in [4]. -Matthias [1] http://tinyurl.com/6etwfe [2] http://tinyurl.com/5lussu [3] http://tinyurl.com/5c2qq7 [4] https://issues.apache.org/jira/browse/TRINIDAD-1142 -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
