+1
And if we create a context parameter, it should behave by default as in the
JSF 2.2 Spec. If users want strict spec (2.0/2.1)behaviour they have to set
the parameter value.
regards
Rudy
On 21 September 2011 17:08, Grant Smith <work.gr...@gmail.com> wrote:
> +1 if it's configurable in a <context-param>. How about
> org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ?
>
> On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz <michi.k...@gmx.at> wrote:
>
>> +1
>>
>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
>>
>> > +1
>> >
>> > 2011/9/21 Leonardo Uribe <lu4...@gmail.com>:
>> >> Hi
>> >>
>> >> More than a year ago, it was found that EL expressions like
>> >> #{cc.attrs.test} does not resolve its type correctly, because the
>> >> composite component EL resolver is not able to find the right type.
>> >> Instead, MapELResolver always return Object.class as type, breaking
>> >> composite components that use h:selectOneXXX into its internals. See
>> >>
>> >> https://issues.apache.org/jira/browse/MYFACES-2552
>> >>
>> >> The problem with this issue is we need to change the way how
>> >> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver
>> >> works. JSF 2.0 spec clearly says in its section 5.6.2.2 that getType()
>> >> for that EL resolver should return null.
>> >>
>> >> The issue was reported to the EG and a fix was included in JSF 2.2.
>> spec, see:
>> >>
>> >> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745
>> >>
>> >> but we still receive reports about the same issue (MYFACES-3311 and
>> >> others (last comment on MYFACES-1890) ).
>> >>
>> >> So, the current behavior even if is described by the spec is too
>> >> inconvenient. Note we already have some places in our implementation
>> >> that does not follow strictly the spec, to keep things working as
>> >> users expect. To follow the protocol in these cases, we need an
>> >> official community decision about include it in 2.0.x and 2.1.x
>> >> branches. Please vote:
>> >>
>> >> +1 if you want this fix included in 2.0.x and 2.1.x.
>> >> +0
>> >> -1 and the reason why if you see this could cause any problem.
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> [1] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> >>
>>
>>
>
>
> --
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
>
>
--
Rudy De Busscher
http://www.c4j.be
