You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "burghard.w.v.britzke (JIRA)" <de...@myfaces.apache.org> on 2008/07/04 21:31:32 UTC

[jira] Created: (TRINIDAD-1142) partial submit (for ppr) does not work for some jsp with a rendered XML-PI

partial submit (for ppr) does not work for some jsp with a rendered XML-PI
--------------------------------------------------------------------------

                 Key: TRINIDAD-1142
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1142
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Components
    Affects Versions:  1.2.8-core
         Environment: Sun AS 9.1 (glassfish), Java 1.5, Mac OS X 10.5.4, Safari + Firefox 3.0
            Reporter: burghard.w.v.britzke


For some JSP with a XML-PI in the rendered result PPR seems not to work.
The response of the PPR request is routed into an empty case of a chained if statement in the js-function _handlePprResponse() in file DebugCommon1_2_8.js.

20723 else
20723 {
20724 // FIXME: log an error
20725 }

This is because the rootNodeName is "parseerror", which is not checked in the chained if statement.
The parse error occures because two XML-PI are packed together in the response. 
The response looks like

<?xml version="1.0" encoding="UTF-8" ?>
<?xml version="1.0" ?>
<?Tr-XHR-Response-Type ?>
...

The last two PI come from trinidad directly. The first one is the rendered result out of the JSP.
The JSP looks like:

<?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 title="test">
 ...
It seems that the jsp servlet pushes its <jsp:text>-content (in this case the XML-PI) into the response before the PPR engine filters the rendered page.
As a workaround I put the <jsp:text> element into the <f:view> (not above it). So
It is rendered at the beginning of the document but is filtered out during PPR.

The XML-PI which comes from trinidad should use the encoding attribute. Otherwise PPR may fail for documents encoded other than UTF-8.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (TRINIDAD-1142) partial submit (for ppr) does not work for some jsp with a rendered XML-PI

Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/TRINIDAD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Weßendorf resolved TRINIDAD-1142.
------------------------------------------

    Resolution: Invalid

>From Blake Sullivan:
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.


=> I close the issue since that is an unfixed JSP/JSF integration issue.
JSF 2.0 will hopefully address it....

> partial submit (for ppr) does not work for some jsp with a rendered XML-PI
> --------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1142
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1142
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions:  1.2.8-core
>         Environment: Sun AS 9.1 (glassfish), Java 1.5, Mac OS X 10.5.4, Safari + Firefox 3.0 (may be reproduced with other client environments, too)
>            Reporter: burghard.w.v.britzke
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> For some JSP with a XML-PI in the rendered result PPR seems not to work.
> The response of the PPR request is routed into an empty case of a chained if statement in the js-function _handlePprResponse() in file DebugCommon1_2_8.js.
> 20723 else
> 20723 {
> 20724 // FIXME: log an error
> 20725 }
> This is because the rootNodeName is "parseerror", which is not checked in the chained if statement.
> The parse error occures because two XML-PI are packed together in the response. 
> The response looks like
> <?xml version="1.0" encoding="UTF-8" ?>
> <?xml version="1.0" ?>
> <?Tr-XHR-Response-Type ?>
> ...
> The last two PI come from trinidad directly. The first one is the rendered result out of the JSP.
> The JSP looks like:
> <?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 title="test">
>  ...
> It seems that the jsp servlet pushes its <jsp:text>-content (in this case the XML-PI) into the response before the PPR engine filters the rendered page.
> As a workaround I put the <jsp:text> element into the <f:view> (not above it). So
> It is rendered at the beginning of the document but is filtered out during PPR.
> The XML-PI which comes from trinidad should use the encoding attribute. Otherwise PPR may fail for documents encoded other than UTF-8.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TRINIDAD-1142) partial submit (for ppr) does not work for some jsp with a rendered XML-PI

Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610697#action_12610697 ] 

Matthias Weßendorf commented on TRINIDAD-1142:
----------------------------------------------

ok, did the (ugly) fix.
best would be to only send-down one XML-PI.
The JSP one OR the one from the PPR response writer.

> partial submit (for ppr) does not work for some jsp with a rendered XML-PI
> --------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1142
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1142
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions:  1.2.8-core
>         Environment: Sun AS 9.1 (glassfish), Java 1.5, Mac OS X 10.5.4, Safari + Firefox 3.0 (may be reproduced with other client environments, too)
>            Reporter: burghard.w.v.britzke
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> For some JSP with a XML-PI in the rendered result PPR seems not to work.
> The response of the PPR request is routed into an empty case of a chained if statement in the js-function _handlePprResponse() in file DebugCommon1_2_8.js.
> 20723 else
> 20723 {
> 20724 // FIXME: log an error
> 20725 }
> This is because the rootNodeName is "parseerror", which is not checked in the chained if statement.
> The parse error occures because two XML-PI are packed together in the response. 
> The response looks like
> <?xml version="1.0" encoding="UTF-8" ?>
> <?xml version="1.0" ?>
> <?Tr-XHR-Response-Type ?>
> ...
> The last two PI come from trinidad directly. The first one is the rendered result out of the JSP.
> The JSP looks like:
> <?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 title="test">
>  ...
> It seems that the jsp servlet pushes its <jsp:text>-content (in this case the XML-PI) into the response before the PPR engine filters the rendered page.
> As a workaround I put the <jsp:text> element into the <f:view> (not above it). So
> It is rendered at the beginning of the document but is filtered out during PPR.
> The XML-PI which comes from trinidad should use the encoding attribute. Otherwise PPR may fail for documents encoded other than UTF-8.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TRINIDAD-1142) partial submit (for ppr) does not work for some jsp with a rendered XML-PI

Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
    [ https://issues.apache.org/jira/browse/TRINIDAD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610695#action_12610695 ] 

Matthias Weßendorf commented on TRINIDAD-1142:
----------------------------------------------

quick fix could be
calling 'window.location.reload(true);'

> partial submit (for ppr) does not work for some jsp with a rendered XML-PI
> --------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1142
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1142
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions:  1.2.8-core
>         Environment: Sun AS 9.1 (glassfish), Java 1.5, Mac OS X 10.5.4, Safari + Firefox 3.0 (may be reproduced with other client environments, too)
>            Reporter: burghard.w.v.britzke
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> For some JSP with a XML-PI in the rendered result PPR seems not to work.
> The response of the PPR request is routed into an empty case of a chained if statement in the js-function _handlePprResponse() in file DebugCommon1_2_8.js.
> 20723 else
> 20723 {
> 20724 // FIXME: log an error
> 20725 }
> This is because the rootNodeName is "parseerror", which is not checked in the chained if statement.
> The parse error occures because two XML-PI are packed together in the response. 
> The response looks like
> <?xml version="1.0" encoding="UTF-8" ?>
> <?xml version="1.0" ?>
> <?Tr-XHR-Response-Type ?>
> ...
> The last two PI come from trinidad directly. The first one is the rendered result out of the JSP.
> The JSP looks like:
> <?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 title="test">
>  ...
> It seems that the jsp servlet pushes its <jsp:text>-content (in this case the XML-PI) into the response before the PPR engine filters the rendered page.
> As a workaround I put the <jsp:text> element into the <f:view> (not above it). So
> It is rendered at the beginning of the document but is filtered out during PPR.
> The XML-PI which comes from trinidad should use the encoding attribute. Otherwise PPR may fail for documents encoded other than UTF-8.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.