ICEfaces
  1. ICEfaces
  2. ICE-8150

Icefaces3 with MyFaces - Auction - bid table disappearance

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0.BETA2
    • Fix Version/s: 3.1.0.BETA2, 3.1
    • Component/s: QA, Sample Apps
    • Labels:
      None
    • Environment:
      Icefaces3.0 trunk revision# 29153
      Server: tomcat6 v6.0.26
      Browser: FF3.6, IE7 & GoogleChrome19
      Last known working revision# : 29139
    • Assignee Priority:
      P2
    • Affects:
      Compatibility/Configuration

      Description

      clicking on "confirm bid (check)" button after entering a bid, whether an valid or invalid bid, causes the bid table to disappear.

      Run auction on tomcat6 and follow the steps below:

      To reproduce error:

      On auction application, click on the bid textbox to enter a bid (valid or invalid entry).

      Then click the "check" button, which will result in the table to disappear.

      Failed results occured after the MyFaces JSF change from May 22, 2012.

        Activity

        Hide
        Ken Fyten added a comment -

        Apparent MyFaces 2.1.7 regression.

        Show
        Ken Fyten added a comment - Apparent MyFaces 2.1.7 regression.
        Hide
        Deryk Sinotte added a comment -

        Confirmed the regression. I only see the table disappear on a bid entry which is invalid in some way (too big, too low, characters, etc). I can enter valid bids. I'd guess that the difference is related to work done for https://issues.apache.org/jira/browse/MYFACES-3415. Continuing to investigate.

        Show
        Deryk Sinotte added a comment - Confirmed the regression. I only see the table disappear on a bid entry which is invalid in some way (too big, too low, characters, etc). I can enter valid bids. I'd guess that the difference is related to work done for https://issues.apache.org/jira/browse/MYFACES-3415 . Continuing to investigate.
        Hide
        Deryk Sinotte added a comment -

        The validation can be triggered automatically for JSF by putting a character in the bid field where the backing bean setter is expecting a double value.

        From what I can tell, there's a been a very significant overhaul in the UIRepeat code. Part of this seems to include a part that, when validation fails, some portion of the rendering is short-circuited.

        Examing the old and new DOMs during the diffing, it's apparent that the whole ui:repeat section is not in the new DOM. This leads to an update of the tbody that's empty of any content - which is the result we see in the browser.

        Show
        Deryk Sinotte added a comment - The validation can be triggered automatically for JSF by putting a character in the bid field where the backing bean setter is expecting a double value. From what I can tell, there's a been a very significant overhaul in the UIRepeat code. Part of this seems to include a part that, when validation fails, some portion of the rendering is short-circuited. Examing the old and new DOMs during the diffing, it's apparent that the whole ui:repeat section is not in the new DOM. This leads to an update of the tbody that's empty of any content - which is the result we see in the browser.
        Hide
        Deryk Sinotte added a comment -

        I did up a test case with ui:repeat and default validation that doesn't use any ice*.jar libraries but I am not able to replicate the issue yet.

        Show
        Deryk Sinotte added a comment - I did up a test case with ui:repeat and default validation that doesn't use any ice*.jar libraries but I am not able to replicate the issue yet.
        Hide
        Deryk Sinotte added a comment - - edited

        I've modified and checked in the application change. Please retest.

        The problem was related to a special phase listener on the auction.page. The phase listener is called on every request and is supposed to simulate updating the Auction as it might be done via a webservice. The DataRefreshListener eventually leads to the following AuctionController code being called during the before RENDER_RESPONSE phase:

        // apply the new data against the current view data.
        if (auctionBean.getAuctionItems() != null)

        { auctionBean.setAuctionItems(mergeAuctionData(auctionItems, auctionBean.getAuctionItems())); }

        In the mergeAuctionData method, the collection is cleared. Removing that line allows the application to work normally:

        Index: src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java
        ===================================================================
        — src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java (revision 29219)
        +++ src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java (revision 29220)
        @@ -152,7 +152,7 @@
        }
        }
        }

        • currentAuctionItems.clear();
          +// currentAuctionItems.clear();
          return currentAuctionItemBeans;
          }

        The changes to UIRepeat in MyFaces 2.1.7 appear to render the response using this cleared data. This is likely due to the validation short-circuiting the lifecycle. This means the UIRepeat ends up rendering out an empty table. This changes is picked up by the normal DOM diffing logic and ends up having the table removed. Commenting out this method appeared to cause no obvious side effects after testing with MyFaces 2.1.6, 2.1.7 and Mojarra 2.1.6.

        Show
        Deryk Sinotte added a comment - - edited I've modified and checked in the application change. Please retest. The problem was related to a special phase listener on the auction.page. The phase listener is called on every request and is supposed to simulate updating the Auction as it might be done via a webservice. The DataRefreshListener eventually leads to the following AuctionController code being called during the before RENDER_RESPONSE phase: // apply the new data against the current view data. if (auctionBean.getAuctionItems() != null) { auctionBean.setAuctionItems(mergeAuctionData(auctionItems, auctionBean.getAuctionItems())); } In the mergeAuctionData method, the collection is cleared. Removing that line allows the application to work normally: Index: src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java =================================================================== — src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java (revision 29219) +++ src/main/java/org/icefaces/demo/auction/view/controllers/AuctionController.java (revision 29220) @@ -152,7 +152,7 @@ } } } currentAuctionItems.clear(); +// currentAuctionItems.clear(); return currentAuctionItemBeans; } The changes to UIRepeat in MyFaces 2.1.7 appear to render the response using this cleared data. This is likely due to the validation short-circuiting the lifecycle. This means the UIRepeat ends up rendering out an empty table. This changes is picked up by the normal DOM diffing logic and ends up having the table removed. Commenting out this method appeared to cause no obvious side effects after testing with MyFaces 2.1.6, 2.1.7 and Mojarra 2.1.6.
        Hide
        Jerome Ruzol added a comment -

        Re-tested auction. The previous issues of the disappearing tables has been resolved although, a new issue is that a user would need to click the check button twice in order for him/her to initiate a bid.

        Show
        Jerome Ruzol added a comment - Re-tested auction. The previous issues of the disappearing tables has been resolved although, a new issue is that a user would need to click the check button twice in order for him/her to initiate a bid.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Jerome Ruzol
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: