Just in case it helps, I'm also having problems with HtmlSelectOne:
This used to work until last week.
Leonardos patch in MYFACES-2356.3 fixes this problem.
I'd say this is a blocker for the beta release...
LieGrue,
strub
2010-01-26 13:25:27.623:WARN::/reservation-fe/reservationRequest.jsf
java.lang.IllegalArgumentException: Expected submitted value of type String for
component : {Component-Path : [Class:
org.ajax4jsf.component.AjaxViewRoot,ViewId: /reservationRequest.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: suchformular][Class:
org.richfaces.component.html.HtmlGraphValidator,Id: j_id9][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: wellKnown]}
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:275)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRadioRendererBase.encodeEnd(HtmlRadioRendererBase.java:97)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:486)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:612)
at
org.richfaces.component.UIGraphValidator.encodeChildren(UIGraphValidator.java:268)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:603)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:107)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
--- On Tue, 1/26/10, Michael Kurz <michi.k...@gmx.at> wrote:
> From: Michael Kurz <michi.k...@gmx.at>
> Subject: Re: MyFaces binding problem with HtmlSelectOneMenu/SelectOneChoice
> To: users@myfaces.apache.org
> Date: Tuesday, January 26, 2010, 10:22 AM
> Hi Simon,
>
> as you already have noticed, a component binding is not the
> right place
> to get the value of a component. The reason is simple: on a
> postback
> (submit) the component binding setter is called in the
> restore view
> phase where the value of the component is not yet set. In
> this phase not
> even the submitted value is yet set for the component.
>
> On the first submit the value is set after your setter was
> called.
> Therefore you can't see it before the second submit.
>
> If you are interested you can have a look at [1] for
> details (I assume
> you speak german).
>
> regards
> Michael
>
> [1]: http://jsfatwork.irian.at/semistatic/jsf.html#idx:/jsf.html:2.6
>
> Am 25.01.2010 14:35, schrieb schneidc:
> >
> > Hi,
> >
> > I tried both drop down menus, MyFaces's
> HtmlSelectOneMenu and Trinidad's
> > SelectOneChoice and both seem to have the same problem
> or at least I can't
> > understand their behaviour.
> >
> > The menus are bound to an according object in a
> managed bean and the setter
> > looks like this:
> >
> > public void
> setSelectOne(CoreSelectOneChoice selectOne) {
> > this.selectOne =
> selectOne;
> >
> if(selectOne.getValue() != null)
> >
>
> System.out.println(selectOne.getValue().toString());
> > else
> >
> System.out.println("broker null");
> > }
> >
> > the tags:
> >
> >
> <tr:selectOneChoice id="menu0"
> inlineStyle="margin-left: 20px"
> > binding="#{createTransactionModel.selectOne}">
> >
> <tr:selectItem
> label="Broker" value="broker" />
> >
> <tr:selectItem
> label="Customer" value="customer" />
> >
> </tr:selectOneChoice>
> >
> > The very first time I call a page I get "broker null"
> as expected. Then I
> > push a button which causes a submit and the setter
> get's called again but
> > although I SELECTED a value I still get "broker null".
> When I push the
> > button a second time I finally get a not null value.
> >
> >
> > And if it wasn't confusing enough the behaviour
> differs from App Server to
> > App Server. The above behaviour was observed on a
> Websphere App Server. On a
> > Glassfish instead I get "broker null" when the page is
> called for the first
> > time (ok so far) and when I hit a button
> > "broker null"
> > "broker != null"
> > as output straight one after another.
> >
> >
> > Can somebody explain to me this behaviour? Especially
> why I only get a not
> > null value on the WAS after causing a submit a second
> time?
> >
> >
> > Cheers
> > Simon
>
