I agree STRICT_JSF_2_COMPATIBILITY is too generic. I think the param should contain EL, TYPE, MAP, RESOLVER, NULL. And it should enabled by default.
Regards Bernd On Wed, Sep 21, 2011 at 11:50 PM, Mark Struberg <[email protected]> wrote: > 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 >> >
