ICEfaces
  1. ICEfaces
  2. ICE-11229

Submitting a form containing an ace:list that has been modified throws javax.faces.model.NoRowAvailableException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: EE-4.2.0.GA
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Oracle Linux 6, Payara 4.1.1.163
    • Assignee Priority:
      P3

      Description

      If you remove the last entry of the list value of an ace:list, submitting the form containing the list throws an Exception.
      1. AceListBean.java
        0.7 kB
        William Saxton
      2. aceListBean.xhtml
        1 kB
        William Saxton

        Activity

        Hide
        William Saxton added a comment -

        Click the X button next to the "Last" entry in the ace:list which removes it from the list. Then click the "Submit" button. This will throw the exception. Removing the "First" or "Second" entries will not.

        Show
        William Saxton added a comment - Click the X button next to the "Last" entry in the ace:list which removes it from the list. Then click the "Submit" button. This will throw the exception. Removing the "First" or "Second" entries will not.
        Hide
        William Saxton added a comment - - edited

        For those people that are stuck, there is a very onerous workaround to this issue where you can maintain an extra entry in the last position of the backing list such as:

        backingList.add("blank")

        And then you can make this entry invisible with CSS (for example, if your bodyClass is "blockList":

        .blockList .if-list-item:last-child

        { display:none }

        You just have to make sure you maintain the "blank" entry @ the end of the list, no matter what kind of adding/removing you do to the list. I just have this inside all of my add/remove functions:

        backingList.remove("blank");
        // manipulate the list however you want
        backingList.add("blank");

        Show
        William Saxton added a comment - - edited For those people that are stuck, there is a very onerous workaround to this issue where you can maintain an extra entry in the last position of the backing list such as: backingList.add("blank") And then you can make this entry invisible with CSS (for example, if your bodyClass is "blockList": .blockList .if-list-item:last-child { display:none } You just have to make sure you maintain the "blank" entry @ the end of the list, no matter what kind of adding/removing you do to the list. I just have this inside all of my add/remove functions: backingList.remove("blank"); // manipulate the list however you want backingList.add("blank");
        Hide
        Carmen Cristurean added a comment -

        Unable to reproduce the error with the attached test case, with the ICEfaces 4.1.1 release libraries, on Payara-Web 4.1.1.164 (Web Profile), GlassFish5, Tomcat7.

        Show
        Carmen Cristurean added a comment - Unable to reproduce the error with the attached test case, with the ICEfaces 4.1.1 release libraries, on Payara-Web 4.1.1.164 (Web Profile), GlassFish5, Tomcat7.
        Hide
        Carmen Cristurean added a comment - - edited

        I reproduced the 'NoRowAvailableException' error on Payara/GlassFish5 by adding a constructor to the AceListBean.java:
        public AceListBean(List<String> list)

        { super(); this.list = list; }

        This error cannot be reproduced on Tomcat.

        Removing the "@Named" annotation from the bean makes this error disappear on Payara/GlassFish5.

        Show
        Carmen Cristurean added a comment - - edited I reproduced the 'NoRowAvailableException' error on Payara/GlassFish5 by adding a constructor to the AceListBean.java: public AceListBean(List<String> list) { super(); this.list = list; } This error cannot be reproduced on Tomcat. Removing the "@Named" annotation from the bean makes this error disappear on Payara/GlassFish5.
        Hide
        Judy Guglielmin added a comment -

        rev 51373 resolves this issue. It should be noted that the problem could be replicated using JSF managed beans and did not require CDI to reproduce. I will attach a CDI project that can also be tested on Tomcat 8 though (using maven). You would have to install the SNAPSHOT from rev 51373 to test it using maven. The QA test also has been modified to use JSF annotations for testing.

        Show
        Judy Guglielmin added a comment - rev 51373 resolves this issue. It should be noted that the problem could be replicated using JSF managed beans and did not require CDI to reproduce. I will attach a CDI project that can also be tested on Tomcat 8 though (using maven). You would have to install the SNAPSHOT from rev 51373 to test it using maven. The QA test also has been modified to use JSF annotations for testing.
        Hide
        Judy Guglielmin added a comment -

        issue with deploying the aceListCDI war to payara was the context.xml file in the war. It is for tomcat only and loads tomcat classes so that was the exception on Payara. Just remove this file from the war and it deploys fine.

        Show
        Judy Guglielmin added a comment - issue with deploying the aceListCDI war to payara was the context.xml file in the war. It is for tomcat only and loads tomcat classes so that was the exception on Payara. Just remove this file from the war and it deploys fine.
        Hide
        Ken Fyten added a comment -

        Re-open to reclassify as Invalid, since no product changes are required to resolve.

        Show
        Ken Fyten added a comment - Re-open to reclassify as Invalid, since no product changes are required to resolve.
        Hide
        Ken Fyten added a comment -

        Re-open to mark Fixed again, as there was a code change requires to resolve the original issue.

        Show
        Ken Fyten added a comment - Re-open to mark Fixed again, as there was a code change requires to resolve the original issue.

          People

          • Assignee:
            Judy Guglielmin
            Reporter:
            William Saxton
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: