Hi, Both suggestions for a name are reasonable, because they suggest different things!
What Leo suggested (STRICT_JSF_2_COMPATIBILITY), is the flag we (internally) have been discussing (and postponing) for a long time. This config parameter would enable us to include non-spec behavior in MyFaces core, which would make us fail the TCK, if we included it by default. However, by enabling it via config parameter only (STRICT_JSF_2_COMPATIBILITY=false), we would be able to fix obvious spec issues already in MyFaces core 2.0 (e.g. MYFACES-2552) and still passing the TCK. Thus we would not need to wait for the next spec release (which may not even contain the fix....), to fix critical issues. What Mark and Bernd suggested is to include the fix for MYFACES-2552 and make a config parameter just for this behavior. Actually, I think introducing yet another config parameter for (in this case) very specific behavior is not the best idea, b/c no-one outside of the MyFaces developers will use it. Introducing a more generic config param, which would allow us to fix a lot more issues which are just like this one, is IMO a far better idea. Thus, my vote is +1 for STRICT_JSF_2_COMPATIBILITY and +0 for Bernd's suggestion. Regards, Jakob 2011/9/22 Martin Marinschek <mmarinsc...@apache.org>: > +1 in general, +1 to Bernd's suggestion. > > best regards, > > Martin > > On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek > <gerhard.petra...@gmail.com> wrote: >> @bernd: +1 >> 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/22 Bernd Bohmann <bernd.bohm...@atanion.com> >>> >>> 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 <strub...@yahoo.de> 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 <jakob.korh...@gmail.com> >>> >> To: MyFaces Development <dev@myfaces.apache.org> >>> >> Cc: gudnabr...@gmail.com >>> >> 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 <lu4...@gmail.com>: >>> >>> 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 <lu4...@gmail.com>: >>> >>>> 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 <strub...@yahoo.de>: >>> >>>>> 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 <gudnabr...@gmail.com> >>> >>>>>> To: MyFaces Development <dev@myfaces.apache.org> >>> >>>>>> 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 >>> >>>>>> <gerhard.petra...@gmail.com> 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 <rdebussc...@gmail.com> >>> >>>>>>>> >>> >>>>>>>> +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 >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Jakob Korherr >>> >> >>> >> blog: http://www.jakobk.com >>> >> twitter: http://twitter.com/jakobkorherr >>> >> work: http://www.irian.at >>> >> >>> > >> >> > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
