Not sure about that. Does the param start with javax.faces? In this case we should rather use an own internal one.
Btw, if it's not in the spec even Mojarra would not be allowed to use a proprietary parameter with "javax...." LieGrue, strub ----- Original Message ----- > From: Matt Benson <[email protected]> > To: MyFaces Development <[email protected]> > Cc: > Sent: Wednesday, September 21, 2011 6:29 PM > Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches > > +1 > > However, let's simplify the context parameter by giving it a name > relating to JSF 2.2 compatibility. I submitted the final > implementation for Mojarra, so have every right to add the same to > MyFaces. > > Matt > > On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek > <[email protected]> wrote: >> +1 for it in combination with the context parameter >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2011/9/21 Rudy De Busscher <[email protected]> >>> >>> +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 <[email protected]> > 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 > <[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. >>>> >>> >>> >>> >>> -- >>> Rudy De Busscher >>> http://www.c4j.be >>> >> >> >
