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

Michael Kurz commented on MYFACES-3311:
---------------------------------------

Hi Martin,

when the value is null, conversion and validation won't be called anyway - so 
at least for that aspect we are on the safe side.

I did another debugging round and saw that MapELResolver always returns 
Object.class from getType() (at least Tomcat 7 implementation).

If the component is outside a cc, the BeanELResolver is used, which determines 
the type of the property directly.

So the problem is the indirection via the cc attributes map (where the property 
value is not even set in some cases as I saw - getType() can't even see it).

Best regards,
Michi

> Can't resolve converter for cc attributes
> -----------------------------------------
>
>                 Key: MYFACES-3311
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3311
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.1.3
>            Reporter: Michael Kurz
>         Attachments: MYFACES-3311-testapp.zip
>
>
> I have some serious problems with composite component attributes. I have a 
> composite component with the attribute value. This attribute 
> (#{cc.attrs.value}) is mapped to the value attribute of an internal 
> h:inputText. When I pass a VE to the composite component, the value is not 
> converted in the h:inputText.
> The problem is caused in _SharedRendererUtils.findUIOutputConverter(). In 
> this method the converter is resolved based on the type returned by a call to 
> getType() on the VE. Unfortunately, for the VE in the composite component 
> (#{cc.attrs.value}) this resolves to java.lang.Object (and not to 
> java.lang.Long in my case).
> I quickly tried to replace the call to VE.getType() with a call to 
> getValue().getClass(). This works, but I guess this introduces additional 
> constraints I'm currently not aware of. Any ideas? Wasn't something like this 
> already discussed in the past?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to