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 >>> >> >> >> >
