issue with and ajax response writer

[Matthias Wessendorf <ma...@apache.org>]

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

Re: issue with and ajax response writer

[Matthias Wessendorf <ma...@apache.org>]

Talked to Blake Sullivan about this. He said:
<bs>
The short answer is that with JSF, the page author should pretty much
never attempt to set the encoding in any way--this is the
responsibility of the ViewHandler and messing with this is JSP can
only screw the ViewHandler up.

I assume that the bad response handling code that is invoked when we
have extra XML processing instructions is what is causing the reload.
In theory, we could ignore extra processing instructions in this case,
but doing so is probably more trouble than it is worth.
</bs>

So, as I already expected... I will close the issue, since that is a
JSP/JSF integration issue
(like some other that aren't yet fixed)

-Matthias

On Sat, Aug 30, 2008 at 4:08 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> 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
>



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