Sorry I suggested to enable this parameter as default You only need to know this parameter if you need the old behavoir
Regards Bernd On Thu, Sep 22, 2011 at 1:30 PM, Michael Kurz <[email protected]> wrote: > OK, good. But: This would then be parameter 94 to consider? > > Best regards > Michi > > Am 22.09.2011 13:17, schrieb Mark Struberg: >> >> of course there is: >> >> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> >>> From: Michael Kurz<[email protected]> >>> To: MyFaces Development<[email protected]> >>> Cc: >>> Sent: Thursday, September 22, 2011 1:14 PM >>> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches >>> >>> I agree with Jakob, nobody will know about a parameter like this (are >>> they documented anywhere btw?). The effect (without setting it): for >>> application developers JSF seems to be broken. >>> >>> Best regards >>> Michi >>> >>> Am 22.09.2011 12:16, schrieb Jakob Korherr: >>>> >>>> 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<[email protected]>: >>>>> >>>>> +1 in general, +1 to Bernd's suggestion. >>>>> >>>>> best regards, >>>>> >>>>> Martin >>>>> >>>>> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek >>>>> <[email protected]> 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<[email protected]> >>>>>>> >>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> http://www.irian.at >>>>> >>>>> Your JSF powerhouse - >>>>> JSF Consulting, Development and >>>>> Courses in English and German >>>>> >>>>> Professional Support for Apache MyFaces >>>>> >>>> >>>> >>>> >>> >
