Shouldnt the config contain the text EL_TYPE or so? We have far too many strict JSF spec flags already ;)
LieGrue, strub ----- Original Message ----- > From: Jakob Korherr <[email protected]> > To: MyFaces Development <[email protected]> > Cc: [email protected] > Sent: Wednesday, September 21, 2011 10:20 PM > Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches > > +1 for including the fix in 2.0.x and 2.1.x + adding > org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY > > Regards, > Jakob > > 2011/9/21 Leonardo Uribe <[email protected]>: >> Hi >> >> @Matt Benson: Could you attach at least the fragment with the solution >> for MYFACES-2552 ? so I can check it, create a patch for myfaces and >> write a page on: >> >> https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components >> >> with the explanation and the solution using a custom EL resolver. That >> would be very helpful. >> >> regards, >> >> Leonardo Uribe >> >> 2011/9/21 Leonardo Uribe <[email protected]>: >>> Hi >>> >>> It should be a param starting with org.apache.myfaces, like >>> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY >>> >>> The important part is that by default it should be disabled, to >>> prevent receive over and over the same report. >>> >>> In theory, it is possible to write a custom EL resolver that check if >>> the base object implements >>> javax.faces.el.CompositeComponentExpressionHolder and if that so, do >>> the required stuff only on getType(). So, if somebody is writing a >>> composite component that relies on this behavior, it is possible to >>> write the fix in a portable way to both Mojarra and MyFaces (thanks to >>> CompositeComponentExpressionHolder). >>> >>> Note the change does not cause any side effects, because nobody relies >>> on the "wrong" behavior, and what user wants is components > work as >>> expected. >>> >>> regards, >>> >>> Leonardo Uribe >>> >>> 2011/9/21 Mark Struberg <[email protected]>: >>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
