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 <[email protected]>
Sent by: [email protected]
06.03.2010 09:56
Please respond to
"MyFaces Discussion" <[email protected]>
To
MyFaces Discussion <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
> Sent by: [email protected]
>
>
> 02.03.2010 23:39
> Please respond to
> "MyFaces Discussion" <[email protected]>
>
>
>
> To
> MyFaces Discussion <[email protected]>
> 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 <[email protected]>
>
> > 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 <[email protected]>
> > Sent by: [email protected]
> >
> >
> > 01.03.2010 17:50
> > Please respond to
> > "MyFaces Discussion" <[email protected]>
> >
> >
> >
> > To
> > MyFaces Discussion <[email protected]>
> > 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 <[email protected]>
> >
> > > 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 <[email protected]>
> > > Sent by: [email protected]
> > >
> > >
> > > 01.03.2010 12:25
> > > Please respond to
> > > "MyFaces Discussion" <[email protected]>
> > >
> > >
> > >
> > > To
> > > MyFaces Discussion <[email protected]>
> > > 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 <[email protected]>
> > >
> > > > 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.
*****************************************************************
