MyFaces Core
  1. MyFaces Core
  2. MYFACES-2881

Server state saving with two forms, ajax and normal request is broken

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.1, 2.0.2-SNAPSHOT
    • Fix Version/s: 2.1.0
    • Component/s: General
    • Labels:
      None
    • Environment:
      myfaces 2.0.1 or trunk;

      Description

      Use simple xhtml with:

      <h:form id="form1">
      <h:commandButton value="Partial">
      <f:ajax execute="@this" render="@this" />
      </h:commandButton>
      </h:fom>

      </h:form>
      <h:form id="form2">
      <h:commandButton value="Full" />
      </h:form>

      then:
      1) click "Partial" button 20x or more
      2) click "Full" button
      -> ViewExpiredException appears. If you click "Partial" 19 times or less ViewExpiredException does not appear.

      20 is default for NUMBER_OF_VIEW_IN_SESSION - it you set this param to 1 you reproduce this problem with two clicks. Maybe there is more simple test case for reproducing this issue but I didn't find it yet.

      This bug is present in 2.0.1 already and is related to server state saving:
      myfaces 2.0.1:

      PSS + server: failed
      PSS + client: ok
      FSS + server: failed
      FSS + client: ok

      myfaces 2.0.2-SNAPSHOT:

      PSS + server: failed
      PSS + client: ok
      FSS + server: failed
      FSS + client: ok

      Very likely this causes MYFACES-2877 too.

        Activity

        Hide
        Werner Punz added a comment -

        Not a bug, but a deficit from the spec regarding the viewstate handling, the problem is by spec definition and by limitations regarding portlet environments I cannot update all viewstates from all forms.

        The spec says only the issuing forms viewstate can be updated, i extended that in my code to all forms which have updated elements, because since I do not have a portlet detection from the javascript side I cannot detect which forms are part of the viewroot affected.

        So I cannot fix it directly but I have coded a workaround in, simply either update form2 as well or one element which is located in form 2.

        Show
        Werner Punz added a comment - Not a bug, but a deficit from the spec regarding the viewstate handling, the problem is by spec definition and by limitations regarding portlet environments I cannot update all viewstates from all forms. The spec says only the issuing forms viewstate can be updated, i extended that in my code to all forms which have updated elements, because since I do not have a portlet detection from the javascript side I cannot detect which forms are part of the viewroot affected. So I cannot fix it directly but I have coded a workaround in, simply either update form2 as well or one element which is located in form 2.
        Hide
        Werner Punz added a comment -

        This cannot be fixed within myfaces without changes in the spec, but a workaround is to refresh the second form as well or one element within the form.
        (note for mojarra to get this working you probably have to refresh the second form)

        In the end this problem has to be fixed on the spec side of things, a bugreport on it has been filed by me a while ago, we probably either need a portlet detection case or even better a protocol extension, which extends
        the viewstate handling with dedicated form ids instead of just issuing the viewstate element.

        Show
        Werner Punz added a comment - This cannot be fixed within myfaces without changes in the spec, but a workaround is to refresh the second form as well or one element within the form. (note for mojarra to get this working you probably have to refresh the second form) In the end this problem has to be fixed on the spec side of things, a bugreport on it has been filed by me a while ago, we probably either need a portlet detection case or even better a protocol extension, which extends the viewstate handling with dedicated form ids instead of just issuing the viewstate element.
        Hide
        Werner Punz added a comment -

        Here is my integration testcase for this behavior:

        <script type="text/javascript">
        function sendQueued(event) {
        for (var cnt = 0; cnt != 500; cnt++) {
        jsf.ajax.request(document.getElementById('queued'), event, {execute:'@this', render:'refresh refreshtrigger'/*, myfaces:

        {transportType: "iframeQueuedPost"}

        */});
        }
        return false;
        }
        </script>

        <h:form id="form" prependId="false">
        <h:commandLink id="button2"
        onclick="jsf.ajax.request(this,event,

        {execute:'@this', render:'form form2'}

        ); return false;"
        action="#

        {myBean2.doSearch}

        " value="press me for next ajax"
        >
        <!-- note by refreshing this outputtext we mark the form as viewstate updateable as well, this only works in myfaces --->
        <h:outputText id="refreshtrigger"/>
        </h:commandLink>
        </h:form>

        ....
        <h:form id="form2" prependId="false">
        <h:panelGroup id="content">
        <h:panelGroup id="refresh">
        #

        {myBean2.refresh}

        </h:panelGroup>

        <h:commandLink id="queued" value="queued"
        onclick="sendQueued(event);return false;">
        </h:commandLink>
        </h:panelGroup>
        </h:form>
        ....

        Show
        Werner Punz added a comment - Here is my integration testcase for this behavior: <script type="text/javascript"> function sendQueued(event) { for (var cnt = 0; cnt != 500; cnt++) { jsf.ajax.request(document.getElementById('queued'), event, {execute:'@this', render:'refresh refreshtrigger'/*, myfaces: {transportType: "iframeQueuedPost"} */}); } return false; } </script> <h:form id="form" prependId="false"> <h:commandLink id="button2" onclick="jsf.ajax.request(this,event, {execute:'@this', render:'form form2'} ); return false;" action="# {myBean2.doSearch} " value="press me for next ajax" > <!-- note by refreshing this outputtext we mark the form as viewstate updateable as well, this only works in myfaces ---> <h:outputText id="refreshtrigger"/> </h:commandLink> </h:form> .... <h:form id="form2" prependId="false"> <h:panelGroup id="content"> <h:panelGroup id="refresh"> # {myBean2.refresh} </h:panelGroup> <h:commandLink id="queued" value="queued" onclick="sendQueued(event);return false;"> </h:commandLink> </h:panelGroup> </h:form> ....
        Hide
        Martin Kočí added a comment -

        Hi Werner,

        yes I'm aware about multiform problem handling: your mail here: http://www.mail-archive.com/jsr-314-open@jcp.org/msg00043.html and spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790

        I've reported similiar bug (but it was regression): MYFACES-2762. But in mojarra it is working without any additions: just try example from MYFACES-2877 with mojarra 2.0.3 or 2.1 SNAPSHOT.

        I don't fully understand why myfaces shouldn't support it now:

        • RI supports it
        • it's a specification bug
        • not supporting this makes JSF ajax unsuable - ajax and partial lifecycle is designed for minimizing network traffic - adding all h:form as targets for render is step back and puts additional burden to users.

        I think this is similar case as coercion in EL (https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183): specification contains bug and this bug costs hours of time (http://www.irian.at/blog/blogid/unifiedElCoercion/#unifiedElCoercion)

        Show
        Martin Kočí added a comment - Hi Werner, yes I'm aware about multiform problem handling: your mail here: http://www.mail-archive.com/jsr-314-open@jcp.org/msg00043.html and spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790 I've reported similiar bug (but it was regression): MYFACES-2762 . But in mojarra it is working without any additions: just try example from MYFACES-2877 with mojarra 2.0.3 or 2.1 SNAPSHOT. I don't fully understand why myfaces shouldn't support it now: RI supports it it's a specification bug not supporting this makes JSF ajax unsuable - ajax and partial lifecycle is designed for minimizing network traffic - adding all h:form as targets for render is step back and puts additional burden to users. I think this is similar case as coercion in EL ( https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183): specification contains bug and this bug costs hours of time ( http://www.irian.at/blog/blogid/unifiedElCoercion/#unifiedElCoercion )
        Hide
        Werner Punz added a comment - - edited

        Hi Martin Mojarra seems to have fixed the issue in 2.0.3, it was not working for 2.0.2, but the main issue here is the mechanism, if they really fixed it by updating all forms, then they broke definitely portlets that way, which was a major issue why I pulled the update all forms from my code and introduced the marker elements cause form updates code.

        But to give you a full picture I have to give you a complete history of the issue.

        I discovered this bug sometime after 2.0 was released and immediately tested against Mojarra (2.0.2 back then). Mojarra had some fixup code which worked only if you had the element updated as child of the form, but it failed if the form was not even touched.
        I then implemented an all forms update solution, and brought the entire issue to the expert group and also filed a bugreport.
        Then someone pointed out in a bugreport that the update all forms solution cannot work in a portlet specific environment where you have multiple viewroots. Now the next problem I am facing here is that there is no viewroot detection.

        So I tried to opt for a solution which basically works satisfactory and does not break compatibility to mojarra. I did this by the mechanism described above,
        a) Update all forms which nest elements which are updated, update the original form consisting the issuing element, and update all forms which might have been childs of updated elements.

        That way you can write code which works on both platforms and does not break any compatibility to future upgrades in this area. If this is not satisfactory then I will need a viewroot detection mechanism coming from the server which can give me a dedicated viewroot id in a portlet scenario, than I can move over to an update all forms mechanism.

        Another option to resolve this would be to reuse the existing script config param no_portlet_env to enable the update all forms mechanism. None of this is entirely satisfactory because the first one has to be added ont he server, the second one
        is not a plug and play mechanism. Or inverse that param so that it can be set in a portlet environment.

        And the issue is, I have filed all this to the EG for 2.1 I hope it will be tackled and resolved, this issue has been a major pain for me for ages.

        Sorry for my bitter tone on this issue, but I have been fighting for a clean solution here for months now, tried to make a solution for all scenarii without breaking the spec, filed bug reports to all parties and even to Mojarra and then again getting smacked again for a bug which I did not even introduce firsthand.

        The criticism regarding Mojarra doing and and we don´t makes me especially bitter since I filed the bugreport on this one for Mojarra and I tried to find a sane solution which works in a portlet and non portlet scenario until this can be resolved properly on spec level.
        I have not dug into the code what Mojarra does, but I assume they repeated my mistake I did firsthand by just updating all forms given and not doing anything regarding portlets.

        Show
        Werner Punz added a comment - - edited Hi Martin Mojarra seems to have fixed the issue in 2.0.3, it was not working for 2.0.2, but the main issue here is the mechanism, if they really fixed it by updating all forms, then they broke definitely portlets that way, which was a major issue why I pulled the update all forms from my code and introduced the marker elements cause form updates code. But to give you a full picture I have to give you a complete history of the issue. I discovered this bug sometime after 2.0 was released and immediately tested against Mojarra (2.0.2 back then). Mojarra had some fixup code which worked only if you had the element updated as child of the form, but it failed if the form was not even touched. I then implemented an all forms update solution, and brought the entire issue to the expert group and also filed a bugreport. Then someone pointed out in a bugreport that the update all forms solution cannot work in a portlet specific environment where you have multiple viewroots. Now the next problem I am facing here is that there is no viewroot detection. So I tried to opt for a solution which basically works satisfactory and does not break compatibility to mojarra. I did this by the mechanism described above, a) Update all forms which nest elements which are updated, update the original form consisting the issuing element, and update all forms which might have been childs of updated elements. That way you can write code which works on both platforms and does not break any compatibility to future upgrades in this area. If this is not satisfactory then I will need a viewroot detection mechanism coming from the server which can give me a dedicated viewroot id in a portlet scenario, than I can move over to an update all forms mechanism. Another option to resolve this would be to reuse the existing script config param no_portlet_env to enable the update all forms mechanism. None of this is entirely satisfactory because the first one has to be added ont he server, the second one is not a plug and play mechanism. Or inverse that param so that it can be set in a portlet environment. And the issue is, I have filed all this to the EG for 2.1 I hope it will be tackled and resolved, this issue has been a major pain for me for ages. Sorry for my bitter tone on this issue, but I have been fighting for a clean solution here for months now, tried to make a solution for all scenarii without breaking the spec, filed bug reports to all parties and even to Mojarra and then again getting smacked again for a bug which I did not even introduce firsthand. The criticism regarding Mojarra doing and and we don´t makes me especially bitter since I filed the bugreport on this one for Mojarra and I tried to find a sane solution which works in a portlet and non portlet scenario until this can be resolved properly on spec level. I have not dug into the code what Mojarra does, but I assume they repeated my mistake I did firsthand by just updating all forms given and not doing anything regarding portlets.
        Hide
        Werner Punz added a comment - - edited

        Hi I did an additional testrun against Mojarra 2.0.3 again. The status in 2.0.2 was that it only could assign properly the viewstate if the second form was part of the render part.

        First it worked on the testcase I have given above, but then:

        I tried again, added a bunch of inputs in both forms and then changed the inputs on one side while doing 500 refreshes.
        Then I submitted the second form, and mojarra gave me the lost viewroot exceptiom which we have all come to love so much. So this means following.

        a) Mojarra does some additional state saving optimisations by skipping entirely non changed view states from the history.
        Hence if you dont have any inputs which change their values mojarra always will restore the same viewstate here.
        We probably dont do this for security reasons because we also have alternating public keys in our viewstate.

        b) Mojarras behavior regarding the viewstate handling has not changed, to resolve it properly you have to push the second form into the render part otherwise it wont work. Sorry to say that, but the myfaces solution in this regard is better.

        So to make the code working on both side of things, you simply have to push the second form into the render part, myfaces simply is more tolerant than Mojarra by allowing also outer elements of forms and inner elements of forms in their render part.

        I could copy the behavior from Mojarra in this area but I guess this is not a good idea

        Btw. I also repeated the same test for myfaces and it worked. So the issue here simply is

        Mojarra seems to be recycling non changed savestates which made your code work because you did not have too much changes while testing, but in the end it would have failed as well, because the second form is not part of the render part of your ajax request.

        Myfaces has failed earlier because it does not recycle the savestates, definitely an area which we might be able to improve, I guess, given that the savestating is a performance killer.
        Myfaces has somewhat more tolerant but Mojarra backwards compatible methods on how to enable multi form ajax.

        To make your implementation work use Mojarras method and push the second form as well into the render part of your f:ajax tag.

        Show
        Werner Punz added a comment - - edited Hi I did an additional testrun against Mojarra 2.0.3 again. The status in 2.0.2 was that it only could assign properly the viewstate if the second form was part of the render part. First it worked on the testcase I have given above, but then: I tried again, added a bunch of inputs in both forms and then changed the inputs on one side while doing 500 refreshes. Then I submitted the second form, and mojarra gave me the lost viewroot exceptiom which we have all come to love so much. So this means following. a) Mojarra does some additional state saving optimisations by skipping entirely non changed view states from the history. Hence if you dont have any inputs which change their values mojarra always will restore the same viewstate here. We probably dont do this for security reasons because we also have alternating public keys in our viewstate. b) Mojarras behavior regarding the viewstate handling has not changed, to resolve it properly you have to push the second form into the render part otherwise it wont work. Sorry to say that, but the myfaces solution in this regard is better. So to make the code working on both side of things, you simply have to push the second form into the render part, myfaces simply is more tolerant than Mojarra by allowing also outer elements of forms and inner elements of forms in their render part. I could copy the behavior from Mojarra in this area but I guess this is not a good idea Btw. I also repeated the same test for myfaces and it worked. So the issue here simply is Mojarra seems to be recycling non changed savestates which made your code work because you did not have too much changes while testing, but in the end it would have failed as well, because the second form is not part of the render part of your ajax request. Myfaces has failed earlier because it does not recycle the savestates, definitely an area which we might be able to improve, I guess, given that the savestating is a performance killer. Myfaces has somewhat more tolerant but Mojarra backwards compatible methods on how to enable multi form ajax. To make your implementation work use Mojarras method and push the second form as well into the render part of your f:ajax tag.
        Hide
        Werner Punz added a comment -

        Mojarra does not do it as well it just has a better savestate recycling. The solution is the same on both platforms by pushing the second form into the render part.
        Myfaces just is more tolerant because you can push any element nested in the form or an outer parent of the form as well into the render part!

        Show
        Werner Punz added a comment - Mojarra does not do it as well it just has a better savestate recycling. The solution is the same on both platforms by pushing the second form into the render part. Myfaces just is more tolerant because you can push any element nested in the form or an outer parent of the form as well into the render part!
        Hide
        Martin Kočí added a comment -

        That's good explanation, thank you! I really appreciate it, you do excellent job.

        I clarify here why I found it (again) and why it is so important for us (maybe helpful for others): my team provides templates, components and many other things to others teams to ease their development. Because we don't know structure of their projects we cannot anticipate any structure of forms. And here one of the problems I found: not long ago we added a small "messeger system" in template - simple poll component in own h:form pings periodically to server and shows messages from queue (like "User XY is now in system"). But unfortunately this "steals" ViewState from other forms - result is then unexpected ViewExpired.

        We also use trinidad and richfaces in some projects but I din't notice this problem with trinidad ppr or ajax4j - probably they don't care about portlet environment?

        If you have patch which turns on all forms update mechanism with no_portlet_env = true, can you attach it please? I will be very grateful!

        Show
        Martin Kočí added a comment - That's good explanation, thank you! I really appreciate it, you do excellent job. I clarify here why I found it (again) and why it is so important for us (maybe helpful for others): my team provides templates, components and many other things to others teams to ease their development. Because we don't know structure of their projects we cannot anticipate any structure of forms. And here one of the problems I found: not long ago we added a small "messeger system" in template - simple poll component in own h:form pings periodically to server and shows messages from queue (like "User XY is now in system"). But unfortunately this "steals" ViewState from other forms - result is then unexpected ViewExpired. We also use trinidad and richfaces in some projects but I din't notice this problem with trinidad ppr or ajax4j - probably they don't care about portlet environment? If you have patch which turns on all forms update mechanism with no_portlet_env = true, can you attach it please? I will be very grateful!
        Hide
        Werner Punz added a comment - - edited

        HI, I will patch something in with my next commit, which will probably come on monday.
        For Trinidad and richfaces, I guess they have their own fixup code either in a listener, or by altering the partial response and adding their own stuff (which is more likely)

        But as I said, you might run into the same issue with Mojarra, they simply only update
        other forms if they ar parts of their render targets. I did a testing and could reproduce the issue there.

        Anyway once the code is in I will drop the explanation for it here, I will reopen the issue again.

        Addendum: There is a way to fix it for both impls, here is the deal, first I will enable the updateallforms mechanism for myfaces, but I will drop a code snippet here which will add a listener which fixes it for both impls. So expect all of this on monday probably around the afternoon. Mojarra does not have this fixed, so fixing it from the outside with a listener might be the cleanest way, but that does not really prevent me from enabling it via a config param in myfaces from the inside.

        Show
        Werner Punz added a comment - - edited HI, I will patch something in with my next commit, which will probably come on monday. For Trinidad and richfaces, I guess they have their own fixup code either in a listener, or by altering the partial response and adding their own stuff (which is more likely) But as I said, you might run into the same issue with Mojarra, they simply only update other forms if they ar parts of their render targets. I did a testing and could reproduce the issue there. Anyway once the code is in I will drop the explanation for it here, I will reopen the issue again. Addendum: There is a way to fix it for both impls, here is the deal, first I will enable the updateallforms mechanism for myfaces, but I will drop a code snippet here which will add a listener which fixes it for both impls. So expect all of this on monday probably around the afternoon. Mojarra does not have this fixed, so fixing it from the outside with a listener might be the cleanest way, but that does not really prevent me from enabling it via a config param in myfaces from the inside.
        Hide
        Werner Punz added a comment -

        Ok Martin, first of all sorry to be so harsh in my responses, I hope you have not gotten it wrong.

        I have issued the patch for myfaces so that you can turn on the update all forms either globally or locally here is an example:

        function sendQueuedFormFixup(event) {
        for (var cnt = 0; cnt != 500; cnt++) {
        jsf.ajax.request(document.getElementById('queued'), event, {execute:'@this', render:'refresh', myfaces:{no_portlet_env: true}});
        }
        return false;
        }

        if you add myfaces:

        {no_portlet_env: true}

        then you can use the better viewstate fixup.
        You also can turn it on globally by adding following script part after your jsf.js include

        //initialize the namespace
        window.myfaces = window.myfaces || {};
        myfaces.config = myfaces.config || {};
        //set the config part
        myfaces.config.no_portlet_env = true;

        But I think there might be a solution which might fix the issue for both myfaces and mojarra over a listener.
        I will prototype it out and if it works out I will add that code as well. Because as I said, this code here fixes the issue for myfaces but it wont work for mojarra which also has the same issue.

        Show
        Werner Punz added a comment - Ok Martin, first of all sorry to be so harsh in my responses, I hope you have not gotten it wrong. I have issued the patch for myfaces so that you can turn on the update all forms either globally or locally here is an example: function sendQueuedFormFixup(event) { for (var cnt = 0; cnt != 500; cnt++) { jsf.ajax.request(document.getElementById('queued'), event, {execute:'@this', render:'refresh', myfaces:{no_portlet_env: true}}); } return false; } if you add myfaces: {no_portlet_env: true} then you can use the better viewstate fixup. You also can turn it on globally by adding following script part after your jsf.js include //initialize the namespace window.myfaces = window.myfaces || {}; myfaces.config = myfaces.config || {}; //set the config part myfaces.config.no_portlet_env = true; But I think there might be a solution which might fix the issue for both myfaces and mojarra over a listener. I will prototype it out and if it works out I will add that code as well. Because as I said, this code here fixes the issue for myfaces but it wont work for mojarra which also has the same issue.
        Hide
        Werner Punz added a comment -

        Ok I coded an external solution as well which you can apply:

        function fixViewStates(data) {
        if (data.status == "success") {
        //do the viewstate post processing here
        var responseXML = data.responseXML;
        if (!responseXML) return;

        //first fetch the update element holding the viewstate
        var viewStateVal = null;
        var foundUpdates = responseXML.getElementsByTagName("update");
        if (!foundUpdates) return;
        for (var cnt = foundUpdates.length - 1; viewStateVal == null && cnt >= 0; cnt -= 1) {
        if (foundUpdates[cnt].getAttribute("id") == "javax.faces.ViewState")

        { viewStateVal = foundUpdates[cnt].firstChild.nodeValue; }

        }

        if (!viewStateVal) return;

        for (var cnt = document.forms.length - 1; cnt >= 0; cnt -= 1)

        { //viewstate is in a cdata block _setVSTForm(document.forms[cnt], viewStateVal); }

        }
        }

        function _setVSTForm(theForm, viewstateVal) {
        var viewStateField = (theForm.elements) ? theForm.elements["javax.faces.ViewState"] : null;//this._Dom.findFormElement(elem, this.P_VIEWSTATE);

        if (viewStateField)

        { viewStateField.value = viewstateVal; }

        else if (!viewStateField) {
        var element = document.createElement("div");
        element.innerHTML = ["<input type='hidden' name='", "javax.faces.ViewState" ,"' value='" , viewstateVal , "' />"].join("");
        try

        { theForm.appendChild(element.childNodes[0]); }

        finally {
        element.innerHTML = "";
        //ie gc screwup fixup
        if ("undefined" != typeof element.outerHTML)

        { element.outerHTML = ""; }

        }
        }
        }

        you can use this function as a listener:

        jsf.ajax.request(document.getElementById('queued3'), event,

        {execute:'@this', render:'refresh', onevent: fixViewStates}

        );

        if you send the function down as onevent handler or register it as global handler it also will fix the viewstate for mojarra properly in a non portlet environment.
        This solution definitely works over both implementations and fixes the issue properly.

        Show
        Werner Punz added a comment - Ok I coded an external solution as well which you can apply: function fixViewStates(data) { if (data.status == "success") { //do the viewstate post processing here var responseXML = data.responseXML; if (!responseXML) return; //first fetch the update element holding the viewstate var viewStateVal = null; var foundUpdates = responseXML.getElementsByTagName("update"); if (!foundUpdates) return; for (var cnt = foundUpdates.length - 1; viewStateVal == null && cnt >= 0; cnt -= 1) { if (foundUpdates [cnt] .getAttribute("id") == "javax.faces.ViewState") { viewStateVal = foundUpdates[cnt].firstChild.nodeValue; } } if (!viewStateVal) return; for (var cnt = document.forms.length - 1; cnt >= 0; cnt -= 1) { //viewstate is in a cdata block _setVSTForm(document.forms[cnt], viewStateVal); } } } function _setVSTForm(theForm, viewstateVal) { var viewStateField = (theForm.elements) ? theForm.elements ["javax.faces.ViewState"] : null;//this._Dom.findFormElement(elem, this.P_VIEWSTATE); if (viewStateField) { viewStateField.value = viewstateVal; } else if (!viewStateField) { var element = document.createElement("div"); element.innerHTML = ["<input type='hidden' name='", "javax.faces.ViewState" ,"' value='" , viewstateVal , "' />"] .join(""); try { theForm.appendChild(element.childNodes[0]); } finally { element.innerHTML = ""; //ie gc screwup fixup if ("undefined" != typeof element.outerHTML) { element.outerHTML = ""; } } } } you can use this function as a listener: jsf.ajax.request(document.getElementById('queued3'), event, {execute:'@this', render:'refresh', onevent: fixViewStates} ); if you send the function down as onevent handler or register it as global handler it also will fix the viewstate for mojarra properly in a non portlet environment. This solution definitely works over both implementations and fixes the issue properly.
        Hide
        Werner Punz added a comment -

        Ok lets close the issue again, I provided a patch for myfaced to enable it and an external way to fix the viewstate which works on both impls.
        The final fix will be 2.1 which will get a protocol change regarding the viewstates or a viewroot detection method.

        Show
        Werner Punz added a comment - Ok lets close the issue again, I provided a patch for myfaced to enable it and an external way to fix the viewstate which works on both impls. The final fix will be 2.1 which will get a protocol change regarding the viewstates or a viewroot detection method.
        Hide
        Martin Kočí added a comment -

        Thank you! I used the myfaces.config.no_portlet_env = true; solution.

        Show
        Martin Kočí added a comment - Thank you! I used the myfaces.config.no_portlet_env = true; solution.

          People

          • Assignee:
            Unassigned
            Reporter:
            Martin Kočí
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development