Return-Path: X-Original-To: apmail-myfaces-dev-archive@www.apache.org Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 76E2A73BD for ; Thu, 22 Sep 2011 11:15:02 +0000 (UTC) Received: (qmail 91955 invoked by uid 500); 22 Sep 2011 11:15:02 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 91916 invoked by uid 500); 22 Sep 2011 11:15:02 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 91909 invoked by uid 99); 22 Sep 2011 11:15:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2011 11:15:02 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of michi.kurz@gmx.at designates 213.165.64.23 as permitted sender) Received: from [213.165.64.23] (HELO mailout-de.gmx.net) (213.165.64.23) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 22 Sep 2011 11:14:58 +0000 Received: (qmail invoked by alias); 22 Sep 2011 11:14:36 -0000 Received: from chello080109081154.12.15.univie.teleweb.at (EHLO [192.168.0.198]) [80.109.81.154] by mail.gmx.net (mp045) with SMTP; 22 Sep 2011 13:14:36 +0200 X-Authenticated: #5497346 X-Provags-ID: V01U2FsdGVkX19Lfh8JKx5LjqQoND7cSJXzGpzGB0ZnWL+x780Etc 9T5Vls7HcU3ImD Message-ID: <4E7B189C.6050803@gmx.at> Date: Thu, 22 Sep 2011 13:14:36 +0200 From: Michael Kurz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: MyFaces Development Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches References: <1316627371.69581.YahooMailNeo@web27805.mail.ukl.yahoo.com> <1316641833.64951.YahooMailNeo@web27803.mail.ukl.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: >> +1 in general, +1 to Bernd's suggestion. >> >> best regards, >> >> Martin >> >> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek >> 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 >>>> >>>> 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 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 >>>>>> To: MyFaces Development >>>>>> Cc: gudnabrsam@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: >>>>>>> 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: >>>>>>>> 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: >>>>>>>>> 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 >>>>>>>>>> To: MyFaces Development >>>>>>>>>> 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 >>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> +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 >>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> +1 if it's configurable in a >>>>>> . How about >>>>>>>>>>>>> >>>>>> org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ? >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz >>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 21.09.2011 um 14:20 schrieb Leonardo Uribe: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > +1 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > 2011/9/21 Leonardo Uribe >>>>>> : >>>>>>>>>>>>>> >> 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 >> > > >