+1 In general for fixing this issue. I'm not firm with the current spec version though. Would we do it the same way as it is planed for 2.2 or is the spec a step behind?
In any case introducing a Context param for configuring the behaviour is a good idea. LieGrue, strub >________________________________ >From: Grant Smith <[email protected]> >To: MyFaces Development <[email protected]> >Sent: Wednesday, September 21, 2011 5:08 PM >Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches > > >+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 <[email protected]> wrote: > >+1 >> >>Am 21.09.2011 um 14:20 schrieb Leonardo Uribe: >> >> >>> +1 >>> >>> 2011/9/21 Leonardo Uribe <[email protected]>: >>>> 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. > > > >
