myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: Trouble upgrading from 1.1.2 to 1.1.7
Date Mon, 08 Mar 2010 16:20:11 GMT
Hi Sébastien,

It's great that you were able to figure out the real problem :)

To explain it a little further: the <f:selectItem itemValue="1" .../>
creates a SelectItem with the String value of "1". If you want to provide an
Integer value you have to provide it via a property in a managed bean that
returns the integer 1. maybe also #{1} will work, but I'm not really sure...

I totally agree that there should be a document (wiki-page etc.) that
describes such changes. Unfortunately this was far before my time.. However,
if we apply similar changes to MyFaces 2.0, I will write them down on a wiki
page, I promise ;)

Regards,
Jakob

2010/3/8 <s.pennec@lombardodier.com>

> Hello Jakob,
>
> Don't worry for the delay, that's great to have support for this kind of
> problems :-)
>
> First, I changed all the attributes that did not work to String, so that
> the page worked again. Then I chose one of the attributes and tried the
> following configurations:
>
> - int property -> KO
> - Integer property -> KO
> - Integer property and explicit converter:
> (javax.faces.convert.IntegerConverter registered in my own
> faces-config.xml) -> KO
> - String property -> OK
>
> Since the field was mapping to a "greater or smaller than" filter value, I
> had not set the page to display an error corresponding to this field. So I
> added the following line to my JSPX:
> <ice:message for="myOperator" styleClass="errorMsg"/>
>
> With this line, I can now see an error message, saying that my value is
> not a valid option. Here is how the field is written in the JSPX:
>
> <ice:selectOneMenu value="#{listController.filter.myOperator}" id=
> "myOperator">
>   <f:selectItem itemValue="1" itemLabel="#{msg.search_filter_greater}" />
>  <f:selectItem itemValue="-1" itemLabel="#{msg.search_filter_less}" />
> </ice:selectOneMenu>
>
> I see the call in the IntegerConverter, and can trace it until it is in
> the UIInput.java class:
>
> if (!isValid()) return;
> validateValue(context, convertedValue);
> if (!isValid()) return;
>
> The first call to "isValid()" returns true, and the second call returns
> false.
>
> By digging a little bit further, I found this, in UISelectOne.java, in
> method "validateValue(FacesContext context, Object value)" :
> // selected value must match to one of the available options
> if (!_SelectItemsUtil.matchValue(value, new _SelectItemsIterator(this)))
> {
>  _MessageUtils.addErrorMessage(context, this, INVALID_MESSAGE_ID, new
> Object[] {getId()});
>  setValid(false);
> }
>
> The condition here returns true, meaning that the validation fails. And
> ever further down in SelectItemsUtil.java, method "matchValue(Object
> value, Iterator selectItemsIter)":
> Object itemValue = item.getValue();
> if (value==itemValue || (itemValue.equals(value))) {
>  return true;
> }
>
> In this condition, the Integer value that has just been created is tested
> for equality with the String value that is in the SelectItem. The
> validation obviously cannot pass. In version 1.1.2, the same method
> contained the following code:
>
> Object itemValue = item.getValue();
> if(converter != null && itemValue instanceof String)
> {
>  itemValue = converter.getConvertedValue(context, (String)itemValue);
> }
> if (value==itemValue || value.equals(itemValue))
> {
>  return true;
> }
>
> This code changed the value of the variable "itemValue" to the converted
> value when a converter was available, and thus tested two Integer objects
> for equality.
> I think this explains why setting the property to String works in 1.1.7,
> and leaving the property as an int or Integer, as it used to work in
> 1.1.2, doesn't work anymore.
> Searching through MyFaces' JIRA, with a clearer view of the problem lead
> me to this issue: [1], which explicitly changed the code that is printed
> here above. Several persons pointed out the fact that this change of
> behavior would be an upgrade problem for users migrating MyFaces. But
> since the change was making MyFaces behave more closer to the RI, I guess
> it made sense to do it anyway.
>
> More generally speaking, I think that somebody at MyFaces should build and
> maintain a document listing all upgrade-breaking changes that are found as
> the development goes on. It is time-consuming to have to diagnose a
> problem like I had to do, and seeing that the code has been changed
> knowing that it would cause upgrade problems is just plain annoying. Maybe
> this document already exists, but my search for upgrade problems with
> MyFaces did not lead me to it.
>
> Anyway, thanks Jakob for your support :-)
>
> Best regards,
>
> Sébastien
>
> [1] http://issues.apache.org/jira/browse/MYFACES-1328
>
>
>
>
>
>
>
> Jakob Korherr <jakob.korherr@gmail.com>
> Sent by: sethfromaustria@gmail.com
>
>
> 06.03.2010 09:56
> Please respond to
> "MyFaces Discussion" <users@myfaces.apache.org>
>
>
>
> To
> MyFaces Discussion <users@myfaces.apache.org>
> cc
>
> Subject
> Re: Trouble upgrading from 1.1.2 to 1.1.7
>
>
>
>
>
>
> Hi Sébastien,
>
> Sorry for the long delay - I had to learn a lot last week for a university
> exam...
>
> Anyway, the thing with iceSubmit() was just a guess. I thought that maybe
> ICEfaces causes some kind of a wrong submit data or something like that.
> However, it really bugs me that this does not work out for you! A version
> upgrade should not be a loss of functionality!
>
> The next thing you/we could take a look at is the conversion mechanism.
> Maybe this does not work right, because your String properties work
> (right?)
> and your int properties don't. Have you tried setting a converter manually
> at the component which is bound to the int property? The standard integer
> converter's class is javax.faces.convert.IntegerConverter.  Altough this
> class is registered in the standard-faces-config.xml for type int and
> java.lang.Integer, it may not be applied (why ever..).
>
> Another thing you could try is changing the property from the native int
> type to java.lang.Integer. Maybe this will work.
>
> Hope this helps!
>
> Regards,
> Jakob
>
> 2010/3/3 <s.pennec@lombardodier.com>
>
> > Hi Jakob,
> >
> > I guess that the javascript in iceSubmit() might not the cause of the
> > problem... The int binding that used to work doesn't work anymore, and
> > this is what caused the interface to "freeze". Correcting the java code
> to
> > accept a String made the interface work correctly again....
> >
> > I fail to understand how does the javascript iceSubmit() fits in this...
> > but I certainly am not the most knowledgable person on the matter. Could
> > you explain what makes you think that the javascript might be a good
> > suspect?
> >
> > Since I have a release planned in a quite short time, I won't be able to
> > rewrite the whole form using only MyFaces components... sorry about
> > that... :( But I might have the time to build a sample-app that shows
> that
> > the binding that used to work doesn't work anymore. As I understood
> them,
> > the release notes of MyFaces do not show anything related to this change
> > of behavior. Do you think it might be a bug?
> >
> > Regards,
> >
> > Sébastien
> >
> >
> >
> >
> >
> >
> >
> >
> > Jakob Korherr <jakob.korherr@gmail.com>
> > Sent by: sethfromaustria@gmail.com
> >
> >
> > 02.03.2010 23:39
> > Please respond to
> > "MyFaces Discussion" <users@myfaces.apache.org>
> >
> >
> >
> > To
> > MyFaces Discussion <users@myfaces.apache.org>
> > cc
> >
> > Subject
> > Re: Trouble upgrading from 1.1.2 to 1.1.7
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > You're welcome ;)
> >
> > Hmm. Maybe the submitting via the javascript function iceSubmit() does
> not
> > function properly. It's really hard to say from this point of view...
> >
> > Have you tried using some of the standard MyFaces components (without
> > ICEFaces)?
> >
> > Regrads,
> > Jakob
> >
> > 2010/3/2 <s.pennec@lombardodier.com>
> >
> > > Hello Jakob,
> > >
> > > Here is the generated HTML of (a part of) a search form. It includes a
> > > "Bigger than/smaller than" field that was bound to an int in my Java
> > code.
> > >
> > > The binding was not working anymore, untill I modified the setter of
> the
> > > attribute to take a String and converted to an int afterwards (just as
> a
> > > quick way of testing if a String binding would work).
> > >
> > > I then changed several other bindings similar to this one to use
> > Strings,
> > > and the app seems to run way better now :-) but anyway further testing
> > > will be necessary.
> > >
> > > HTML:
> > >
> > > <tr class="icePnlGrdRow2">
> > >        <td class="icePnlGrdCol editrQ" id="searchForm:_id1068-1-0">
> > >                <label class="iceOutLbl bold"
> > > for="searchForm:aValueToFilter" id="searchForm:_id1075">Label of the
> > value
> > > to filter</label>
> > >        </td>
> > >
> > >        <td class="icePnlGrdCol editrR" id="searchForm:_id1068-1-1">
> > >                <div class="icePnlGrp" id="searchForm:_id1076">
> > >                        <select style="" class="iceSelOneMnu"
> > > id="searchForm:valueToFilterOperator"
> > > name="searchForm:valueToFilterOperator"
> > >                                onblur="setFocus('');"
> > > onfocus="setFocus(this.id);" size="1">
> > >                          <option value="1">Bigger than or equal
> > > to</option>
> > >                          <option value="-1">Smaller than/option>
> > >                        </select>
> > >
> > >                        <input style="" class="iceInpTxt"
> > > id="searchForm:aValueToFilter" name="searchForm:aValueToFilter"
> > >                          onblur="setFocus('');"
> > > onfocus="setFocus(this.id);" onkeypress="iceSubmit(form,this,event);"
> > > onmousedown="this.focus();"
> > >                          size="15" value="" type="text">
> > >                        <label class="iceOutLbl"
> id="searchForm:_id1079">
> > > unit of the value to filter</label>
> > >
> > >                        <span id="searchForm:_id1080"></span>
> > >                </div>
> > >        </td>
> > > </tr>
> > >
> > > Does it help?
> > >
> > > Thanks a lot for your help...
> > >
> > > Best regards,
> > >
> > > Sébastien
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Jakob Korherr <jakob.korherr@gmail.com>
> > > Sent by: sethfromaustria@gmail.com
> > >
> > >
> > > 01.03.2010 17:50
> > > Please respond to
> > > "MyFaces Discussion" <users@myfaces.apache.org>
> > >
> > >
> > >
> > > To
> > > MyFaces Discussion <users@myfaces.apache.org>
> > > cc
> > >
> > > Subject
> > > Re: Trouble upgrading from 1.1.2 to 1.1.7
> > >
> > >
> > >
> > >
> > >
> > >
> > > Can you provide some generated HTML (not JSP!!), which includes
> > components
> > > that do not work. This could be a great help!
> > >
> > > Regards,
> > > Jakob
> > >
> > > 2010/3/1 <s.pennec@lombardodier.com>
> > >
> > > > Hello,
> > > >
> > > > My guess is that the problem is more general than just a javascript
> > > issue.
> > > >
> > > > In my previous message, I gave the "form submit" situation only as
> an
> > > > example. The problem actually touches more than just this: I cannot
> > sort
> > > > my table content by clicking on one column header, I cannot switch
> > from
> > > a
> > > > StackPanel to another, etc...
> > > >
> > > > By searching a little bit further, I found out that the values that
> I
> > > used
> > > > in combo boxes to show a "greater or smaller" choice (for example,
> age
> > > > greater or smaller than 30) are not bound to their java counterpart
> > > > anymore. For example:
> > > >
> > > > <ice:selectOneMenu value="#{someController.filter.ageOperator}" id=
> > > > "ageOperator">
> > > >  <f:selectItem itemValue="1"
> itemLabel="#{msg.search_filter_greater}"
> > />
> > > >  <f:selectItem itemValue="-1" itemLabel="#{msg.search_filter_less}"
> />
> > > > </ice:selectOneMenu>
> > > >
> > > > This menu was bound to a Java integer as follows:
> > > >
> > > > private int ageOperator;
> > > >
> > > > With 1.1.7, the value is not bound anymore. I needed to change the
> > type
> > > of
> > > > the attribute in my Java class to String for the binding to work
> > again.
> > > Is
> > > > there a special converter that I should add, which was not needed in
> > > 1.1.2
> > > > ? I can assure you that this runs fine with 1.1.2 :-)
> > > >
> > > > I am fairly new to MyFaces. Is there something I should do to make
> the
> > > > upgrade easier?
> > > >
> > > > Thanks a lot for your help :-)
> > > >
> > > > Sébastien
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Jakob Korherr <jakob.korherr@gmail.com>
> > > > Sent by: sethfromaustria@gmail.com
> > > >
> > > >
> > > > 01.03.2010 12:25
> > > > Please respond to
> > > > "MyFaces Discussion" <users@myfaces.apache.org>
> > > >
> > > >
> > > >
> > > > To
> > > > MyFaces Discussion <users@myfaces.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > Re: Trouble upgrading from 1.1.2 to 1.1.7
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Maybe there's a problem with the javascript that submits the form. I
> > saw
> > > > However this is just a shot in the blue...
> > > >
> > > > Regards,
> > > > Jakob
> > > >
> > > > 2010/3/1 <s.pennec@lombardodier.com>
> > > >
> > > > > Hello,
> > > > >
> > > > > I am experiencing quite a lot of trouble while upgrading from
> > MyFaces
> > > > > 1.1.2 to 1.1.7.
> > > > >
> > > > > My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate
> > 3.4.0.
> > > > >
> > > > > The only thing that I changed in my Maven 2 build is the version
> of
> > > > > MyFaces.
> > > > > This had an impact on the following jars:
> > > > >
> > > > > Added:
> > > > > myfaces-api-1.1.7.jar
> > > > > myfaces-impl-1.1.7.jar
> > > > > commons-digester-1.8.jar
> > > > > commons-beanutils-1.8.0.jar
> > > > >
> > > > > Removed:
> > > > > myfaces-api-1.1.2.jar
> > > > > myfaces-impl-1.1.2.jar
> > > > > commons-digester-1.6.jar
> > > > > commons-beanutils-1.7.0.jar
> > > > > commons-codec-1.3.jar
> > > > >
> > > > > When I build and deploy my application in Weblogic 9.2.3, the
> deploy
> > > > goes
> > > > > fine, but the actions in the app do not work anymore.
> > > > > More precisely: as soon as I try to use  JSF components like if I
> > > submit
> > > > a
> > > > > form, then nothing happens. This behaviour can be observed with
> > > several
> > > > > browsers.
> > > > >
> > > > > I tried to find some upgrading guide but didn't find any guide
> > related
> > > > to
> > > > > these versions. And since the version change is minor, I expected
> my
> > > > > application to run fine with the new jars.
> > > > >
> > > > > I tried also tried to override some jar versions, putting back the
> > > > > Digester to version 1.6, and the BeanUtils to version 1.7.0, but
> > this
> > > > > didn't change anything. At this point, the only thing that had
> > changed
> > > > in
> > > > > my EAR were the two MyFaces jars.
> > > > >
> > > > > Another attempt to find the problem was to upgrade the version
> > > > gradually.
> > > > > I switched to MyFaces 1.1.4, and everything worked fine. That's
> when
> > I
> > > > > switched to MyFaces 1.1.5 that the problem appeared. However, I
> > > haven't
> > > > > seen anything in the changes from 1.1.4 to 1.1.5[1] that seems
> > > suspect.
> > > > >
> > > > > Is there some configuration changes that I might have missed? Or
> > some
> > > > > known compatibility problems regarding this upgrade? Again, I
> > couldn't
> > > > > find anything precisely related to these versions up to now, but
> I'm
> > > > still
> > > > > looking.
> > > > >
> > > > > Any help would be highly appreciated! :-)
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Sébastien
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10600&fixfor=12312310&sorter/field=summary&sorter/order=ASC&sorter/field=resolution&sorter/order=ASC&sorter/field=status&sorter/order=ASC&sorter/field=priority&sorter/order=DESC
>
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > ************************ DISCLAIMER ************************
> > > > > This message is intended only for use by the person to
> > > > > whom it is addressed. It may contain information that is
> > > > > privileged and confidential. Its content does not
> > > > > constitute a formal commitment by Lombard Odier
> > > > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > > > If you are not the intended recipient of this message,
> > > > > kindly notify the sender immediately and destroy this
> > > > > message. Thank You.
> > > > > *****************************************************************
> > > > >
> > > >
> > > >
> > > >
> > > > ************************ DISCLAIMER ************************
> > > > This message is intended only for use by the person to
> > > > whom it is addressed. It may contain information that is
> > > > privileged and confidential. Its content does not
> > > > constitute a formal commitment by Lombard Odier
> > > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > > If you are not the intended recipient of this message,
> > > > kindly notify the sender immediately and destroy this
> > > > message. Thank You.
> > > > *****************************************************************
> > > >
> > >
> > >
> > >
> > > ************************ DISCLAIMER ************************
> > > This message is intended only for use by the person to
> > > whom it is addressed. It may contain information that is
> > > privileged and confidential. Its content does not
> > > constitute a formal commitment by Lombard Odier
> > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > If you are not the intended recipient of this message,
> > > kindly notify the sender immediately and destroy this
> > > message. Thank You.
> > > *****************************************************************
> > >
> >
> >
> >
> > ************************ DISCLAIMER ************************
> > This message is intended only for use by the person to
> > whom it is addressed. It may contain information that is
> > privileged and confidential. Its content does not
> > constitute a formal commitment by Lombard Odier
> > Darier Hentsch & Cie or any of its branches or affiliates.
> > If you are not the intended recipient of this message,
> > kindly notify the sender immediately and destroy this
> > message. Thank You.
> > *****************************************************************
> >
>
>
>
> ************************ DISCLAIMER ************************
> This message is intended only for use by the person to
> whom it is addressed. It may contain information that is
> privileged and confidential. Its content does not
> constitute a formal commitment by Lombard Odier
> Darier Hentsch & Cie or any of its branches or affiliates.
> If you are not the intended recipient of this message,
> kindly notify the sender immediately and destroy this
> message. Thank You.
> *****************************************************************
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message