Usually the selectItem values are EJB's, but in a couple of instances they strings that just happen to be the serialized form of the EJB. The prototypical code looks like:
ArrayList projectTypes = new ArrayList( projectTypeHome.findAll() ); for( int i = 0; i < projectTypes.size(); i++ ) { ProjectTypeLocal projectType = (ProjectTypeLocal)projectTypes.get( i ); m_projectTypes.add( new SelectItem( projectType, projectType.getName() ) ); } What this means is when we get to the following lines in _SelectItemsUtil, the equals() method of the EJB is called with the empty ("") string (in 1.1.5): [item is class SelectItem] Object itemValue = item.getValue(); if (value==itemValue || value.equals(itemValue)) It appears that the 1.1.3 code handled the case of any String being passed. Since our converters look for an empty string, this results in the EJB equals() being passed null: Object itemValue = item.getValue(); if(converter != null && itemValue instanceof String) { itemValue = converter.getConvertedValue(context, (String)itemValue); } if (value==itemValue || value.equals(itemValue)) But I guess this circles back to non-standard conversion that was taken out. I'm pretty ignorant of all the JSF lifecycle semantics, but since this practice is always used with required="true", would an earlier check for a non-null, non-empty string fix this? I'm open to suggestions. Mike Kienenberger wrote: > > Yes, I think you're right. It's not the form String -> Object that's > causing the issue. > It looks like it's the contents of the selectItem values. What are > you initializing the selectItem value fields with? > > What's the contents of selectItem.value when it's of type String? > > On 3/30/07, fastbob <[EMAIL PROTECTED]> wrote: >> >> Hmmm. I must be missing something. Other than parameterization, including >> your use of disable and null values, I don't see any significant >> differences >> (I also tried moving the converter into the h:selectOneMenu - no effect). >> In >> fact, the Tomahawk example uses "" as a nothing -selected value, just as >> we >> do. And the converter code is essentially identical - we start with: >> >> if( string == null || string.trim().length() == 0 ) >> return null; >> >> So why are we getting an exception during the validation phase? >> >> Bob >> >> >> Mike Kienenberger wrote: >> > >> > Here's how the tomahawk examples do it: >> > >> > <h:selectOneMenu id="selone_menu_colors" >> > value="#{carconf.color}" styleClass="selectOneMenu" >> > converter="#{carconf.colorConverter}"> >> > <f:selectItem itemValue="" >> > itemLabel="#{example_messages['empty_selitem']}" /> >> > >> > >> > >> > public Object getAsObject(FacesContext facesContext, >> > UIComponent component, String string) throws ConverterException >> > { >> > if(string==null) >> > return null; >> > >> > >> > Here's how I do it on my own projects: >> > >> > public final static String DISABLED_OPTION_VALUE = >> > "com.xyz.utilities.web.jsf.converter.DISABLED_OPTION_VALUE"; >> > public final static String NULL_OPTION_VALUE = >> > "com.xyz.utilities.web.jsf.converter.NULL_OPTION_VALUE"; >> > >> > public String getNullSelectItemOptionValue() { >> > return >> > com.xyz.utilities.web.jsf.converter.ConverterOptions.NULL_OPTION_VALUE; >> > } >> > >> > <f:selectItem >> > itemValue="#{myPage.nullSelectItemOptionValue}" >> > itemLabel="<No selection>" /> >> > >> > public Object getAsObject(FacesContext context, UIComponent >> > component, String value) throws ConverterException >> > { >> > if (null == value) return null; >> > if (ConverterOptions.DISABLED_OPTION_VALUE.equals(value)) >> return >> > null; >> > if (ConverterOptions.NULL_OPTION_VALUE.equals(value)) return >> > null; >> > >> > On 3/30/07, fastbob <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> Mike Kienenberger wrote: >> >> > >> >> > Yes, that's how I would do it. If you specify an itemValue, then >> that >> >> > value must be of the correct type. Ie, " " is not a containerType >> >> > (Srinivas) and "0" is not a region (Carl). >> >> > >> >> Ouch. The assumption is that there is a one-one correspondence between >> >> the >> >> list items and the type in the model. This isn't always the case. >> >> >> >> We had a number of JSP's under 1.1.3 with the following sequence, for >> >> several different types of lists: >> >> >> >> <h:selectOneMenu id="client" value="#{myPage.projectType}"> >> >> <f:converter converterId="x.y.ProjectTypeConverter"/> >> >> <f:selectItem itemValue="" itemLabel="--- Select Project >> >> Type---"/> >> >> <f:selectItems value="#{myPage.projectTypeList}"/> >> >> </h:selectOneMenu> >> >> >> >> The values in the type are fixed (essentially an enumeration, but not >> >> implemented that way), and there is no "empty" value available. >> Instead, >> >> if >> >> the converters are passed a null or empty string for conversion to the >> >> underlying type, they immediately return null. So in this case null is >> >> used >> >> to indicate no value has been selected by the user, and they get an >> >> error. >> >> >> >> With 1.1.5, we get the following exception: >> >> >> >> java.lang.ClassCastException: java.lang.String cannot be cast to >> >> javax.ejb.EJBLocalObject >> >> at >> >> >> org.jboss.ejb.plugins.local.LocalProxy.isIdentical(LocalProxy.java:124) >> >> at >> >> org.jboss.ejb.plugins.local.LocalProxy.invoke(LocalProxy.java:174) >> >> at >> >> org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:40) >> >> at >> >> org.jboss.ejb.plugins.local.LocalProxy.invoke(LocalProxy.java:155) >> >> at >> >> org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:40) >> >> at $Proxy262.equals(Unknown Source) >> >> at >> >> >> javax.faces.component._SelectItemsUtil.matchValue(_SelectItemsUtil.java:65) >> >> at >> >> javax.faces.component.UISelectOne.validateValue(UISelectOne.java:56) >> >> at >> javax.faces.component.UIInput.validate(UIInput.java:354) >> >> at >> >> javax.faces.component.UIInput.processValidators(UIInput.java:184) >> >> […] >> >> >> >> Here are the relevant lines from _SelectItemsUtil.MatchValue(): >> >> >> >> [item is class SelectItem] >> >> Object itemValue = item.getValue(); >> >> if (value==itemValue || value.equals(itemValue)) >> >> >> >> The exception is thrown by the call to equals in an EJB. >> >> >> >> I haven't come up with a low-cost way to fix this. >> >> >> >> Bob >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9762021 >> >> Sent from the MyFaces - Users mailing list archive at Nabble.com. >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9762503 >> Sent from the MyFaces - Users mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/ERROR%3A-Value-is-not-a-valid-option-tf3270984.html#a9797466 Sent from the MyFaces - Users mailing list archive at Nabble.com.