1 Reply Latest reply on Feb 27, 2010 4:45 PM by Frank Cornelis

    h:selectOneRadio binding does not work

    Frank Cornelis Apprentice

      I'm using RichFaces 3.3.3.CR1, Seam 2.2.1-SNAPSHOT, Facelets 1.1.15.B1, JBoss AS 6.0.0.M2.


      I have a @Stateful @Name Seam session bean for a page. It gets called (@PostConstruct @Destroy works) when the page loads. On this page I also have a h:selectOneRadio binding using a HtmlSelectOneRadio setter and getter on that same bean. When clicking the radio button, I get an exception:


      javax.servlet.ServletException: /employee/fulltime.xhtml @19,131 binding="#{fulltimeRequest.typeSelectOne}": Target Unreachable, identifier 'fulltimeRequest' resolved to null
      



      caused by


      javax.el.PropertyNotFoundException: /employee/fulltime.xhtml @19,131 binding="#{fulltimeRequest.typeSelectOne}": Target Unreachable, identifier 'fulltimeRequest' resolved to null
      



      The @PostConstruct of the Seam bean is also not called right before this exception occurs. This means that the JSF binding for somehow reason cannot resolve to the Seam bean. Is this a bug in Seam or am I doing something wrong here?

        • 1. Re: h:selectOneRadio binding does not work
          Frank Cornelis Apprentice

          The weird thing is that marking the HtmlSelectOneRadio field with


          @In(required=false)
          @Out(required=false)
          private HtmlSelectOneRadio typeSelectOne;
          



          works as expected with binding:


          <h:selectOneRadio id="type" binding="#{typeSelectOne}" required="true" layout="pageDirection">
              <f:selectItem itemLabel="#{messages['timeCredit']}" itemValue="timeCredit" />
              <f:selectItem itemLabel="#{messages['themeHoliday']}" itemValue="themeHoliday" />
              <a4j:support event="onclick" action="#{fulltimeRequest.updateRadios}" reRender="themeHoliday"/>
          </h:selectOneRadio>
          



          Now the bean is created and the updateRadios action method on the bean is called as expected. So I definitely think this is a bug in the Seam name resolving.