+1 :) Am 22.09.2011 um 14:15 schrieb Bernd Bohmann:
> 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 >>>>>> >>>>> >>>>> >>>>> >>>> >>
