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

Martin Marinschek commented on MYFACES-3311:
--------------------------------------------

Hi Michi,

I'll say what I know about this topic:

- we can not use java.lang.Long (or any specific type) as the type for a value 
expression, as the EL will try to coerce null to 0 then (that's a very strange 
part of the Unified EL spec)
- however, we can of course get the value and see what the type is. Of course, 
this will not work when the value is null.
- Best would probably be to go over some means independent of the EL to 
determine the type, but I don't know if the API enables us to do this

I wonder if the third suggestion is used when you are outside of a composite 
comp, but not used when you are inside?

best regards,

Martin

> 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