[ 
https://issues.apache.org/jira/browse/MYFACES-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979873#action_12979873
 ] 

Leonardo Uribe commented on MYFACES-3010:
-----------------------------------------

The problem is on the patch applied on MYFACES-2920, we did not take into 
account other cases when a custom class is used and the values are inherited 
from a base class. 

The "context" where this coercion happens, is to compare a itemValue with the 
current value, just to check if the selection submitted is valid. The 
IllegalArgumentException just say that we can't coerce the itemValue to the 
value class, but that does not means the match should fail. Instead, if the 
IllegalArgumentException or any other Exception is thrown, we just fallback to 
use the value without any coercion (in this case selectItem.getValue() ) and 
"swallow" the Exception, because after all, it is no relevant. Note if the 
submitted value can't be matched with a itemValue of the component, an 
Exception will be thrown later. 

The other consideration supporting the "swallow any exception" solution is the 
posibility that EL coercion could be configured in later versions of unified EL.

I think in this case we should wrap the call to _ClassUtils.convertToType in a 
try / catch block, but I would like to add some junit cases first.

> 2.0.3 REGRESSION: javax.faces.component._ClassUtils.convertToType
> -----------------------------------------------------------------
>
>                 Key: MYFACES-3010
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3010
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 2.0.3
>            Reporter: Kennard Consulting
>            Priority: Critical
>         Attachments: addressbook-faces2.zip
>
>
> Hi guys,
> Thanks again for the great work you do on MyFaces and your fantastic JIRA 
> response times!
> I attach a small app that comes from the Metawidget (http://metawidget.org) 
> distribution. I had you do MYFACES-2935 for me for MyFaces 2.0.3, and my app 
> was working great with the 2.0.3-impl-SNAPSHOT.jar and the 2.0.2-api.jar. 
> However now that 2.0.3 is out for real I have tried to upgrade my app, and it 
> fails. To reproduce, please:
> 1. Unzip the attached app and deploy as an exploded WAR into Tomcat
> 2. Run Tomcat and hit http://localhost:8080/addressbook-faces2
> 3. In the Type dropdown, choose 'Business' and click Search
> You will see an IllegalArgumentException. Now:
> 4. Stop Tomcat
> 5. Inside the exploded WAR, rename myfaces-api-2.0.2.rename.me to 
> myfaces-api-2.0.2.jar (and delete/rename myfaces-api-2.0.3.jar)
> 6. Restart Tomcat and repeat steps 1-3
> This time you will see no such error.
> So something appears to have broken between myfaces-api-2.0.2.jar and 
> myfaces-api-2.0.3.jar? Hopefully you can reproduce this and it is enough for 
> you to debug the issue. The source code for the small app can be viewed here:
> http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/faces/addressbook/
> http://metawidget.svn.sourceforge.net/viewvc/metawidget/trunk/examples/src/java/org/metawidget/example/shared/addressbook/
> Of course, this could well be a case of 2.0.3 being stricter about something 
> and therefore exposing a bug in my code. But my code worked in 2.0.2, JSF 1.2 
> and JSF 1.1, so hopefully not!
> Regards,
> Richard

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to