Paul, in my own case, I wasn't reading myfaces email in depth the week
you posted this.   Sometimes things just fall through the cracks
because people are busy with other things.

Sometimes the issue is so obscure that few people really know how to
respond to it.

In both cases, the best thing to do is

1) prove there's a bug.   Either test the same code using the JSF RI
or another version of MyFaces.   Or show that it contradicts the JSF
Specs.   It's best to provide a simplified example demonstrating the
problem -- this would be easy in your particular issue.   The easier
you make it for someone else to look at the problem, the more likely
someone will do so.

2) Provide a patch (like it looks like you're doing above) in JIRA.
If no one has done anything with it, and the bug is proven and the
patch is easily reviewed, feel free to ping the list after a week of
no action.   Repeat weekly until someone either rejects or approves
it, or otherwise responds :-)  Again, having a test case or example
makes it easier to test your patch to verify it should be applied.




On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:

 Thank you for answer, Mike.

 I'm still not sure, weather the second part is really an unrelated spec
issue because it could be just the consequence of the first one.
 So I've decide to describe both together thinking, it can help during code
review since it belongs to very common part of core implementation
 (org.apache.myfaces.shared.renderkit.RendererUtils). If my
suggestion is wrong, the second part can be just ignored. Please see also my
comment to MYFACES-1452, which was the start point of my 'investigation' :)

 I've tried to solve the problem myself, but it was just a partially
solution for me (respectively to second part of MYFACES-1532 description).
Since no one has answered in mailing list, I've thinking my suggestion is
just wrong and haven't provide this as path. But if I'm right, the same
should affect other standard types too (i.e. Date etc.)

 Anyway, here's my code. This method is intended to replace existing
getBooleanValue() in
org.apache.myfaces.shared.renderkit.RendererUtils, which is
called from
org.apache.myfaces.shared.renderkit.html.HtmlCheckboxRendererBase.encodeEnd().
public static Boolean
getBooleanValueForCheckbox(FacesContext facesContext,
 UIComponent component) {
 Object value = getObjectValue(component);

 // This call relays on the implementation of getObjectValue()!!!
 // If uiComponent is not an instance of ValueHolder, the
 // IllegalArgumentException should be already thrown.
 Converter converter = ((ValueHolder) component).getConverter();

 if (null == value || value instanceof Boolean) {
 return (Boolean) value;
 }

 if (null == converter && value instanceof String) {
 // it's still correct to convert String into Boolean, because
 // Boolean provides constructor Boolean(String x)!
 return new Boolean(value.toString());
 }

 // If component provides no custom converter, we
 // must try to obtain a standard one from Application
 if (null == converter) {
 try {
 converter = facesContext.getApplication().createConverter(
 value.getClass());
 } catch (FacesException ex) {
 throw new IllegalArgumentException("Component : "
 + getPathToComponent(component)
 + " expects value of type Boolean.\n"
 + "Neither standard converter for "
 + value.getClass().getName()
 + " nor custom converter provided.");
 }
 }

 if (null != converter) {
 try {

 /* Try to convert it into String. That is!
 * The getAsObject() provides the conversion of string value's
 * representation into custom user type. We are expecting a Boolean,
 * but the value itself is not a Boolean, so we need to get String first.
 */
 String strValue = converter.getAsString(facesContext,
 component, value);

 boolean warn = (null == strValue);
 warn = warn
 || !(strValue.equalsIgnoreCase(Boolean.TRUE.toString()) || strValue
 .equalsIgnoreCase(Boolean.TRUE.toString()));

 if (warn) {
 /* Note that this situation is not an error! We have some
 * converter and it got back some string, and no exception has been
 * thrown!
 */
 log.warn("Component "
 + getPathToComponent(component)
 + " expects value of type Boolean. The value was converted with "
 + converter.getClass().getName()
 + " into "
 + strValue
 + ", what is neither true nor false! false assumed.");
 }

 return new Boolean(strValue);

 } catch (ConverterException ex) {
 throw new IllegalArgumentException("Component : "
 + getPathToComponent(component)
 + " expects value of type Boolean.\n"
 + "Unable to convert " + value.getClass().getName()
 + " into Boolean.");
 }

 } else {
 throw new IllegalArgumentException("Component "
 + getPathToComponent(component)
 + " expects value of type Boolean but "
 + value.getClass().getName() + " was found.");
 }

 }




 regards,
 paul

 Mike Kienenberger schrieb:
On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:

Some other question to Mike. You have just closed MYFACES-1545. I think,
 it's something very similar to MYFACES-1532, I've created 13.02.2007. I
 have asked about this in both of DEV and USERS lists, but nobody has
 answered, so I'm still not sure, whether it's really a bug, or just a
 feature. (There are some other related issues too, however they aren't
 linked to this one.)  Would you please confirm this or close 1532 too?

 Paul, please use a new thread when asking unrelated questions.

 I closed MYFACES-1545 for the reasons listed in the issue, after
 searching the mailing lists for relevent posts by the reporter.  There
 were none.  Custom converters on UISelectOne items are quite common,
 and I've yet to have an issue with them.

 It sounds like there could be a bug in h:selectBooleanCheckbox that
 causes the problem you described in MYFACES-1532.   I've never used a
 converter on this component, and it could very well be as you
 described, so I'm going to leave that open, especially since you
 provided example code.   I vaguely recall issues with the
 convertBoolean converter in the sandbox in the distant past, so it
 wouldn't be at all surprising.

 Again, though, you  have an unrelated second issue described in the
 same issue.   I'd recommend voiding that part and opening another
 issue (although if it's a spec issue, it'll just be closed out of hand
 as those are outside of the scope of MyFaces to handle).



Reply via email to