+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
