myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Kurz (JIRA)" <>
Subject [jira] [Commented] (MYFACES-3311) Can't resolve converter for cc attributes
Date Wed, 21 Sep 2011 05:33:15 GMT


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,

> Can't resolve converter for cc attributes
> -----------------------------------------
>                 Key: MYFACES-3311
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.1.3
>            Reporter: Michael Kurz
>         Attachments:
> 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:


View raw message